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.
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:
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
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.
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.
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
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.
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:
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.
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.
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.
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.
Bdale has just opened up the Garbee and Garbee web store to sell Altus Metrum electronics including TeleMetrum and TeleDongle.
The TeleMetrum boards aren’t quite ready to ship, so they’re marked as ‘out of stock’ for another couple of days. That’s because we’ve decided to switch GPS antennas to improve GPS reception and we won’t have enough of those until Friday to start shipping boards. The TM boards themselves are working great and we’ve flown them several times.
We’ve already sold a couple of TeleDongle boards for use without TeleMetrum. These boards contain the CC1111 transceiver chip along with an 8-pin connector that can be used for USB, SPI or serial communication. This adds long-range wireless digital communication to almost any project. Steve Conklin has posted his plans for these boards. We sell TeleDongle as either bare boards or packaged in a pretty blue box with a USB cable attached.
All of the hardware designs are licensed under the TAPR open hardware license and software under the GPL. All of the tools used to design the hardware and build the software are also free software (already packaged for Debian, of course) so you can take these designs and do whatever you want with them.
Test Flying TeleMetrum v0.2
Bdale and I got a chance to test fly the new version (0.2) of our TeleMetrum flight computers. Bdale flew with the Albuquerque Rocket Society down in New Mexico while I flew near home with Oregon Rocketry during our February model launch.
I flew my Dynastar Grappler which I have modified to create a large payload bay out of a foot of the original body tube:
I cut a sled out of plywood and mounted the TeleMetrum on one side, and a small 110mAh battery on the back:
The field we use for model launches is surrounded by tall fir trees, so we tend to stick to reasonably small motors. This time, I loaded up an Aerotech 24mm E18 motor and trimmed the delay down to about 5 seconds as this rocket uses simple motor ejection. This flight didn’t exercise the new ejection circuitry. In any case, the flight was perfect, telemetry worked all the way down to the ground using just a 1/4 wave whip antenna on the receiver.
Here’s the data recorded in the on-board eeprom:
The maximum reported altitude was 186m, velocity was 49m/s and acceleration was 53m/s².
As expected, the GPS loses tracking during boost, but rapidly re-acquires near apogee and tracks the rocket all the way back to the ground. The flight track can be viewed in Google Earth.
Needless to say, both Bdale and I are extremely pleased with the performance of the new hardware.
Introducing TeleMetrum v0.2
Bdale and I (mostly Bdale, of course) finished the TeleMetrum v0.2 design work in December, and this weekend we got boards made and parts ordered and Bdale sat down with his trusty electric skillet and built 3 new boards. The new design has an integrated GPS receiver and patch antenna, and is otherwise fairly similar in design to v0.1.
TeleMetrum v0.2 Hardware
Here’s the front side of the board:
From the left, you’ll see a connector for an external power switch and the two ejection charge circuits, a battery connector for a single 3.7V lipo cell, the GPS patch antenna, a 4-pin debug connector, the piezo buzzer and the new 8-pin companion board connector. We weren’t happy with the connectors used on the v0.1 board and finally found these Tyco Micro-MaTch parts which take up a modest amount of board space (more than pico-blade connectors, less than regular pin blocks), have a locking option and crimp on to standard ribbon cable. They’re also bright red and surprisingly low in profile.
And here’s the back side:
Elements on this side include the new 100μF cap in the upper left corner which sits on the 3.3V supply to try and keep the CPU alive through minor power glitches. Below that is a new package containing a pair of FETs for the ejection circuits. We used discrete FETs in v0.1, but this device has better specs for our needs (lower on resistance, etc). The USB connector was pulled in-board far enough to keep it from hanging over the edge. Right of that is the new data logging chip, and right of that is a U.FL connector in case you want to use an external GPS antenna. We supply power to that connector as most external GPS antennas include their own LNA. And, of course, to the right of that is the Skytraq Venus 634 GPS receiver.
Below and to the right of the GPS receiver is the cc1111, to the left lies the accelerometer and then the barometric pressure sensor above the 5V boost regulator which powers the accelerometer. We haven’t found any high-G accelerometers that run on 3.3V yet. Finally the two tiny 5-pin chips are the USB LiPo charger and the 3.3V regulator. What you can’t see easily are a pile of 0402 passive components scattered across the board. Even close up, they’re hard to pick out by eye.
The only hardware ‘bug’ was in the reset logic — the new board was designed with a much larger capacitor on the reset line than the old board. The debug code would only hold the reset line low for a brief instant, sufficient for the old capacitor value but not the new one. Instead of fixing the code, Bdale decided to try a smaller capacitor value and found that it worked just fine. After that, the board came up just fine and the updated firmware was flashed into the CPU.
TeleMetrum v0.2 Software
The only significant software change was that the data logging part changed from a 25LC1024 1Mbit eeprom to an AT45DB161D 16Mbit DataFlash. This required writing a new driver, but fortunately much of the code could be copied from the 25LC1024 driver. Because the AT45DB161D comes from a family of similar-but-different parts ranging from 1Mbit to 64Mbits, I decided to make the code automatically adapt to the installed part, detecting which one was attached and adjusting the driver.
The story here is that the configuration data didn’t appear to be getting preserved across reboots — we use the last block of the data logging part to hold configuration data, including call sign, sensor calibration values and flight parameters. A bit of testing and we found that the code to read/write the device worked perfectly. It turns out that a premature optimization in detecting which kind of flash part was installed had a race condition when multiple threads were trying to access storage at the same time, resulting in the configuration data being left uninitialized. Oops!
The TeleMetrum firmware has a clever hack for selecting between ground mode (for fetching data from the device or altering the configuration) and flight mode (prepared to fly the rocket). It switches between these by detecting whether the board is upright (flight mode) or not (idle mode). However, the accelerometer must be calibrated to tell the difference. What never occurred to us was that if the calibration data was broken enough, the device might always come up in flight mode. In that mode, it isn’t listing to either USB or the radio link, so it’s impossible to fix the accelerometer calibration data.
A bit of brainstorming led to a fairly simple hack — check to see if one of the pins on the companion connector was shorted to ground at power on time, if so, force the computer to enter idle mode. Pin 1 of the companion connector is ground, and fortunately, pin 2 was the SPI clock pin, normally output-only, so we could safely use that in this mode as any companion device shouldn’t ever pull that low.
Future Events
As of this evening, three boards are built and mostly tested; the radios appear to work, GPS tracks satellites and the beeper makes plenty of noise. Still to check is whether the deployment circuits will fire an ematch (we’ve tested the design before, just not this specific implementation).
Next weekend, we’re off to linux.conf.au in Wellington, New Zealand where we’re scheduled to give a presentation on the hardware and software in TeleMetrum. We’ll have v0.2 boards to show off, so come and see them in person.
With v0.1, we used the same board design for both flight computer and ground station, TeleDongle. For TeleDongle, we just left most of the components off of the board and loaded alternate firmware. For v0.2, we’re planning on building a separate TeleDongle board; that design is finished but no boards are made yet.
Once we’re happy with the design, we’ve got big plans to get more boards made so we can let a few friends buy them for use them in their own rocket projects. That should happen in the next month or so. Once we’ve gotten enough testing done, and made sure that other people can actually operate them without hand-holding from us, we’ll make them available for sale to the general rocket-flying public.
Beyond that, we’ve got plans to build more stuff:
A stand-alone ground station, called TeleTerra, that would include an LCD readout and flight data recording so you wouldn’t need a laptop during the flight.
A companion board, called TelePyro, to control 8 additional pyro channels. These could be used for almost anything from air starts to staging or any other whacky plans.
To build code for TeleMetrum, we’re using SDCC, the Small Device C Compiler as the CPU inside the cc1111 is an 8051 clone, an 8-bit microprocessor for which SDCC has excellent support (more about the flight software later).
SDCC version 2.9.0 was recently uploaded to Debian unstable, and when I built our flight software with the new version, I discovered a bug in the display of strings formatted by printf. First assuming that the bug was in my source code, I tried to figure out what I’d done wrong, but then I eventually looked that the 8051 assembly output (ick) and discovered that the compiler was generating the wrong code for pointers when passed to a varargs function. A bit of hacking and I soon had a short test case that demonstrated the bug:
extern void f(char *x, ...);
void
func(__xdata char *s)
{
f("hi", s);
}
I filed a brief bug report and attached the test case, then went to download the current source code to see if I couldn’t uncover the source of the bug. I have to say that reading through the SDCC source code was reasonably pleasant; a competent compiler in very little code that was easy to grasp. I eventually located the bug, and discovered that it was from a change made last December as part of a pointer-related optimization, and I posted a patch that I found would fix the specific problem I had found.
The nicest part came next — once I’d posted the patch, a reasonably lively discussion between Maarten Brock, Borut Ražem and Raphael Neider came to a quick concensus about what the desired behavior in this case would be.
Then, Maarten Brock applied my patch to the project and, much to my amazement, he included a regression test that verified the desired behaviour in both the case that I had uncovered and several other cases as well.
I just want to applaud these developers for building a great compiler and running a great project.