Calypso — CalDAV/CardDAV/WebDAV for Android and Evolution

Ever since I bought my first Palm Pilot in 1997, I’ve relied upon a pocket-able device to carry a copy of my calendar and contacts, and for that same database to be present on my laptop. I went through a long list of Palm-compatible devices, including both the Palm Treo and Palm Centro telephones. I even wrote a number of my own Palm applications. Years ago, it was pretty obvious that I’d have to find a new phone, but I was stuck looking for something that could provide the same ‘hot-sync’ functionality.

SyncML on the Series 40

I bought a Series 40 Nokia phone in Shanghai that promised ‘SyncML’ support. Given that I had seen numerous SyncML implementations for Linux, it seemed like I should be able to get something to work.

SyncML on the Series 40 is a disaster — the phone couldn’t actually store all of my contacts, and it couldn’t hold half of the data fields I used. So, that phone landed in the box and back to the Centro I went.

SyncML on the N900

Nokia kindly sent me an N900 at some point, so I gave SyncML another try. Given that the N900 runs evolution-data-server, and that I’ve had evolution-data-server running on my laptop, it seemed like I should be in business. Well, almost. It took several days of hacking to fix bugs in the evolution SyncML back end, then another several days fussing with opensync.

I ended up abandoning direct synchronization as unworkable — opensync would sit in an infinite loop, or worse, trash my database completely. I finally found ‘syncml-ds-tool’, which is a debugging tool that comes with opensync. This tool simply synchronizes a set of disk files, one per contact or calendar entry, with the phone. That worked for well over a year. And then, a few months ago, Bluetooth on the laptop stopped connecting with the phone’s SyncML server. I’d get ‘ECONNREFUSED’ every time I tried to use it. So much for the N900. DUN still worked, mostly, although it too would get ECONNREFUSED at times, but retrying seemed to make it work.

However, While the N900 SyncML solution worked, I discovered another thing I wanted—contacts and calendar entries stored in individual files and revision controlled with git. This makes it reasonable to delete stale calendar entries and know that they’re never really gone, just left behind in an older version of the calendar. And, if you mess up, you can recover by poking at the database with git directly.

I switched back to the venerable Palm Centro; it turns out that calendar and contacts are more important to me than being able to surf the web on my phone. Alas, my Centro went ‘swimming’ in August and has passed on to the great electronics recycling house in the sky. I pulled the SIM out and switched back to the N900.

I got my contacts imported on the N900 by copying files over the net work; not a long-term strategy, but at least I had phone numbers again. There was no hope for my calendar. I started looking for a solution in earnest.

How about Android?

At this point in my story, I’m sure you’re asking why I didn’t just use one of the numerous Android phones that came through my hands. The answer is simple — my calendar and contacts are probably some of my most personal data, and I’m not willing to store them outside of my direct control, for reasons similar to those which are driving the development of the FreedomBox.

When Android first came out, it could only talk to Google services, which didn’t meet my hard requirement for personal data storage.

One of my co-workers had his Google account suspended for violating the terms-of-service; he asked what he had done, but they wouldn’t say. He asked if he could get his data back, and they said “no”. They invited him to create a new account, but it would not ever get any of the old data. A few days later, he got a nice apologetic email letting him know that they’d made a mistake and that he hadn’t, in fact, violated any of the terms-of-service, and that his old account was restored with all of his data intact. Wasn’t that nice of Google?

WebOS?

I got a WebOS phone over the summer and discovered that while it had multiple contact/calendar back ends, none of them used standard protocols and so you only had the choice between multiple corporate data centers, which isn’t actually a choice at all.

Furthermore, the WebOS phone refused route PAN packets over the phone network, even though I have a data plan which allows this. It’s not that it couldn’t support it, it’s that it refused.

A couple of weeks after the WebOS phone arrived, HP canceled all of their WebOS hardware products, which made me less interested in trying to solve this problem.

Android recovers

About the same time the WebOS phone arrived, I discovered that Google had published enough information about the calendar/contacts internals for Marten Gajda to write CalDAV-Sync and CardDAV-Sync. And then, Andrew McMillan wrote aCal, which is a complete replacement for the built-in calendar and contacts applications and supports CalDAV and CardDAV.

With two different standards-compliant solutions available, it seemed like it might be time to try Android again.

I’d love for CardDAV-Sync and CalDAV-Sync to become free software like aCal is. Andrew makes money from aCal by offering it for sale via the Android Market, while still publishing the sources for those who want to build their own copy.

CalDAV/CardDAV on Linux

I think the most widely known CalDAV server for Linux is probably DAViCal, a huge pile of PHP and SQL sitting on top of Apache. I’m sure it’s suitable for running on a server and being accessed over the internet, but I’m not interested in that, nor am I interested in having my laptop run Apache and PostgreSQL.

I found a tiny little CalDAV server, Radicale, which seemed like a lot better fit. It’s written in Python and uses the usual Python HTTP server infrastructure, which provides SSL and authentication support along with some fairly convenient APIs for parsing and generating HTML.

Before long, I discovered that Radicale was actually too simple for my needs. It stores the whole calendar in a single file, re-parsing it whenever a request is made, so a calendar with just hundreds of entries caused the server to slow down enough that evolution would time-out when talking to it.

Also, Radicale doesn’t actually parse the calendar entries completely, it has some ad-hoc code that finds various pieces of data, but without dealing with the whole syntax.

I started hacking at Radicale to see how far I could get. I changed the storage code to store one event per file, then added hooks to use git for change management. Then, I found a full vcalendar/vcard parsing library in python, vobject, which I used to replace the ad-hoc parsing code. Finally, I added support for VCARD entries as well, allowing the system to store both calendar and contact information.

Introducing Calypso, a CardDAV/CalDAV server

With this much divergence from the original project, I’ve figured I’d best rename things to avoid confusion, so I decided to call it ‘calypso’, after a brief trip through the dictionary looking for names starting with ‘ca’.

Calypso works with evolution, iceowl and the Android CalDAV/CardDAV plugins. It does not yet work with aCal; for some reason aCal cannot find any calendars on the server.

Calypso also supports importing calendar changes from the command line, allowing you to integrate support into a text-based email application like notmuch or mutt.

Calypso is available via git from git://keithp.com/git/calypso and is distributed under the GPL (v3 or later). I still consider it a work derived from Radicale, and so the code retains all of the Radicale copyrights along with my own.

Using Calypso

Initial setup

Calypso runs as a regular user, all data are stored in ~/.config/calypso. To initialize calypso:

$ mkdir ~/.config/calypso ~/.config/calypso/calendars
$ cat > ~/.config/calypso/config << EOF
[server]
ssl=true
certificate=/home/keithp/.config/calypso/ssl/server.crt
key=/home/keithp/.config/calypso/ssl/server.key

[acl]
;type=htpasswd
type=fake
filename=/home/keithp/.config/calypso/passwd

Running calypso

Then run calypso:

$ python ./calypso.py

No, I haven’t figured out how to install it…

Creating new calendars

To add a new database:

$ mkdir -p ~/.config/calypso/calendars/private/my_calendar
$ cd ~/.config/calypso/calendars/private/my_calendar
$ git init
$ git commit --allow-empty -m'initialize new calendar'

The new calendar should now be visible as https://localhost:5233/private/my_calendar

You can add files to the directory at any time; calypso will check the directory mtime at each operation and update its internal state from that on disk automatically when the directory changes.

Importing files

Given a set of files with VCALENDAR or VCARD entries, you can import them with:

$ calypso --import private/my_calendar <filenames...>

This will update any changed entries and add any new ones.

ToDo list for calypso

1. Document the config file contents.
2. Make it installable
3. Figure out what aCal wants
4. Support calendar creation

More Android info

• Synker. This provides a desktop widget which starts the sync process running on a list of accounts. This makes it easy to manually synchronize with the laptop when you are connected

• Contact Editor. This lets you fully edit contacts synchronized over CardDAV. The built-in contact editor doesn’t let you change anything other than the name for some reason.

I’m running cyanogenmod on my Nexus S as that provides PAN support. With PAN, I can create a network link between laptop and phone which doesn’t depend on any local WiFi infrastructure and which gives both phone and laptop static IP addresses, allowing me to configure the sync URLs statically on the phone. I’d use mDNS, but Android doesn’t bother to support that.

Fixing the Sandbrige MacBook Air display initialization

We left our hero with Debian installed on the MacBook Air, but with the display getting scrambled as soon as the i915 driver loaded.

As was reported to Matthew, the problem is as simple as a lack of the right mode for the eDP panel in the machine. This mode is supposed to come from the panel EDID data, but for some reason the driver wasn’t able to query the EDID data, and so it decided to try some random panel timings it dug out of the VBT tables, which are generally supposed to be used by LVDS panels. Apple helpfully stuck valid data there, but for some other panel — one that is 1280x800 pixels instead of the 1366x768 pixel panel in the MacBook Air.

I heard rumors that some machines would get a black screen when the i915 driver loaded. I was fortunate — my machine simply displayed a 1366x768 subset of the programmed 1280x800 mode. A bit of garbage on the right side, and a few scanlines missing at the bottom. Quite workable, especially after I ran fbset -yres 768 to keep the console in the visible portion of the screen.

DDC failure

Looking through the kernel logs, the Intel driver tries to access the EDID data and times out, as if DDC is just completely broken. This is rather unexpected; the eDP spec says that the panel is required to support DDC and provide EDID. Now, we’ve seen a lot of panels which don’t quite live up to the rigorous eDP specifications, but it’s a bit surprising from Apple, who generally do VESA stuff pretty well.

We’ve heard reports about panels reporting invalid EDID data, or EDID data which didn’t actually match the panel (causing us to prefer the VBT data on LVDS machines). But I’ve not heard of an eDP panel which didn’t have anything hanging off of the DDC channel.

But X works fine?

During early debugging, I happened to start X up. Much to my surprise, X came up at the native 1366x768 mode. Digging through the kernel logs after that, I discovered that EDID was successfully fetched from the eDP panel while X started up.

At this point, I knew it was all downhill — the EDID data was present, it just wasn’t getting picked up during the early part of the driver initialization when the console mode is initialized.

eDP power management

The CPU is given complete control over the power management of the eDP panel; sequencing through various power states and waiting appropriate amounts of time when things change. Given the goal of keeping power usage as low as possible, this makes a huge amount of sense.

The eDP spec is quite clear though, without power, the panel will not respond to anything over the aux channel, and that includes EDID data. The eDP panel power hardware in the Sandybridge chip has a special mode for dealing with this requirement. If the panel is not displaying data, you can supply power for the aux channel stuff by setting a magic bit in the panel power registers.

When initializing the frame buffer, the kernel driver turns off the panel completely so that it has all of the hardware in a known state (yeah, this is not optimal, but that’s another bug). When X started, the panel was already running with the console mode.

Given the difference between these two states — EDID querying with the panel off failed, while EDID querying with the panel on worked, it seemed pretty clear that the panel power wasn’t getting managed correctly. So, it seemed pretty clear that the magic ‘power the panel’ bit wasn’t getting turned on at the right times.

Getting the power turned on.

I stuck a check inside all of the aux channel communication functions to see where things were broken. This pointed out several places missing the panel power calls. This wasn’t quite sufficient to get EDID data flowing. The remaining problem was that the code wasn’t waiting long enough after turning the panel power on before starting the aux channel communication. A few msleep calls and huzzah! EDID at boot time and the console had the right mode.

Making it faster

However, it turns out that the driver does this a lot, and the msleeps required were fairly long — the eDP panel wants a 500ms delay from turning the panel power off before you can turn it back on.

I fix this by simply delaying the panel power off until things were idle for a ‘long’ time. Now mode setting goes zipping through, and a few seconds later, the bit to force panel power on gets turned off.

Getting these bits for yourself

I’ve pushed out the code to my (temporary) kernel repository git://people.freedesktop.org/~keithp/linux in the fix-edp-vdd-power branch. I’d love to hear if you’ve tried this on either a MacBook Air or any other eDP machine from Ironlake onwards.

Installing Linux on Sandybridge MacBook Air

Matthew Garrett got a report from someone who bought a brand new Sandybridge MacBook Air and was trying to install Fedora on it. The screen went black as soon as the i915 driver tried to set the initial mode.

I bought one to try and help out. Just getting Linux installed turned out to be a minor adventure and I thought I’d write a few notes for the next person who comes along and tries to do this.

The obvious method

I downloaded a collection of Debian ISO images, live images, netboot images from testing and CD-1 of squeeze. I downloaded a Fedora 16 alpha XFCE live image. I burned all of these to actual CDs, and then stuck them in a CD drive and held the ‘c’ key while booting the machine.

Nothing worked. The CD would spin up, the screen would switch from white to a black text mode with a blinking cursor at the upper left and then then CD would stop.

rEFIt attempts

rEFIt provides a boot selection menu and various configuration bits to provide for a multi-boot environment. This is necessary to leave the OS-X install on the disk and also install Linux.

It also lets you boot from removable media, or at least that was the story. rEFIt would list removable USB flash storage devices, but it would not list CD drives, even after the CD drive spun up and did stuff for a while. This makes me wonder if the ‘c’ key technique wasn’t actually trying to boot from the CD.

However, rEFIt wouldn’t boot from a grub2-enabled USB key.

ISO on USB flash key

What rEFIt will boot is a Fedora or Debian ISO image copied directly to the USB flash device. The Ubuntu 11.04 live image and it did not work.

Fedora F16 Alpha

The live image came up and started X in frame buffer mode. However, when I went to install the image to the hard disk, it got stuck trying to discover devices. I waited about 20 minutes and it never finished, although it did chew up a lot of CPU time.

Debian Squeeze

I copied CD-1 of the 32-bit Squeeze distribution to my flash key. That booted up to text mode and went through the install. Nothing really unusual until it came to installing grub. I let it install grub to /dev/sda4, the new partition I had created for Linux. I figured installing grub to /dev/sda would be a bad idea (I think it would have actually worked just fine in retrospect).

A slight out-of-sync diversion here — I couldn’t get the 32-bit kernel to talk to any keyboard or USB networking device, so I eventually installed a 64-bit kernel and that works just fine. You can run a 32-bit user space with a 64-bit kernel without any trouble.

Making EFI boot

Naturally, I couldn’t get the machine to boot to Linux after this. rEFIt, the multi-boot tool for Mac OS X appears only interested in booting EFI images, or at least was not interested in booting my BIOS-based Grub2 installation on /dev/sda4.

I used the ‘rescue’ mode on the USB flash drive to get back to my installed Linux image and installed grub-efi-amd64. The OS X EFI version does not support 32-bit EFI code, which seems entirely reasonable to me.

What took a while was figuring out that all of the grub files need to be readable through EFI, and that the Mac EFI code can only read FAT (and HFS?) partitions.

So, the trick appears to be to stick the grub files on the Mac OS X efi partition (/dev/sda1). I created a directory over there, /EFI/grub and then mounted that as /efi and made a symlink from /boot/grub to /efi/EFI/grub. Now, grub-install sticks the files in the right place, and update-grub will even place grub.cfg in the directory where it needs to go.

At this point, rEFIt will happily find the core.efi and grub.efi files and show them in the list of possible operating systems to boot. I don’t know why there are both core.efi and grub.efi files; I’ve only ever picked ‘grub.efi’ and that has worked nicely.

Broadcom WiFi

I haven’t gotten that working yet; the b43 supported chip list says it works in kernel 3.1. I’m busy building a 3.1-rc4 kernel as I type this, so perhaps that will ‘just work’ when I boot that.

i915 KMS

The whole reason for doing the install is to fix problems with the eDP EDID discovery which is currently preventing the machine from running X. I’ll be working on that next; a quick kludge to just read the current mode from the device should get something on the screen (we already do that for LVDS panels). Beyond that, I’ll be trying to figure out whether I can make EDID actually work, or whether it’s just not available in this machine.

Somehow the kernel frame buffer ended up as 1280x800, which was quite annoying. As a temporary kludge, I ran fbset -yres 768 to at least avoid having text disappear off the bottom of the screen. Once the panel size is discovered correctly, that should be fixed.

Status

This is sure not like installing Linux on a regular PC. However, I’m reasonably hopeful that the devices in the machine will be working pretty well under Debian within the next few days.

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:

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.

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.