Java Sound on Linux

I’m often in the position of having my favorite Java program (AltosUI) unable to make any sounds. Here’s a history of the various adventures I’ve had.

Java and PulseAudio ALSA support

When we started playing with Java a few years ago, we discovered that if PulseAudio were enabled, Java wouldn’t make any sound. Presumably, that was because the ALSA emulation layer offered by PulseAudio wasn’t capable of supporting Java.

The fix for that was to make sure pulseaudio would never run. That’s harder than it seems; pulseaudio is like the living dead; rising from the grave every time you kill it. As it’s nearly impossible to install any desktop applications without gaining a bogus dependency on pulseaudio, the solution that works best is to make sure dpkg never manages to actually install the program with dpkg-divert:

# dpkg-divert --rename /usr/bin/pulseaudio

With this in place, Java was a happy camper for a long time.

Java and PulseAudio Native support

More recently, Java has apparently gained some native PulseAudio support in some fashion. Of course, I couldn’t actually get it to work, even after running the PulseAudio daemon but some kind Debian developer decided that sound should be broken by default for all Java applications and selected the PulseAudio back-end in the Java audio configuration file.

Fixing that involved learning about said Java audio configuration file and then applying patch to revert the Debian packaging damage.

$ cat /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/

You can see the PulseAudio mistakes at the top of that listing, with the corrected native interface settings at the bottom.

Java and single-open ALSA drivers

It used to be that ALSA drivers could support multiple applications having the device open at the same time. Those with hardware mixing would use that to merge the streams together; those without hardware mixing might do that in the kernel itself. While the latter is probably not a great plan, it did make ALSA a lot more friendly to users.

My new laptop is not friendly, and returns EBUSY when you try to open the PCM device more than once.

After downloading the jdk and alsa library sources, I figured out that Java was trying to open the PCM device multiple times when using the standard Java sound API in the simplest possible way. I thought I was going to have to fix Java, when I figured out that ALSA provides user-space mixing with the ‘dmix’ plugin. I enabled that on my machine and now all was well.

$ cat /etc/asound.conf
pcm.!default {
    type plug
    slave.pcm "dmixer"

pcm.dmixer  {
    type dmix
    ipc_key 1024
    slave {
        pcm "hw:1,0"
        period_time 0
        period_size 1024
        buffer_size 4096
        rate 44100
    bindings {
        0 0
        1 1

ctl.dmixer {
    type hw
    card 1

ctl.!default {
    type hw
    card 1

As you can see, my sound card is not number 0, it’s number 1, so if your card is a different number, you’ll have to adapt as necessary.

Posted Sat Apr 5 22:30:55 2014 Tags: rockets

MicroPeak Approved for NAR Contests

The NAR Contest Board has approved MicroPeak for use in contests requiring a barometric altimeter starting on the 1st of April, 2014. You can read the announcement message on the contestRoc Yahoo message board here:

Contest Board Approves New Altimeter

The message was sent out on the 30th of January, but there is a 90 day waiting period after the announcement has been made before you can use MicroPeak in a contest, so the first date approved for contest flights is April 1. After that date, you should see MicroPeak appear in Appendix G of the pink book, which lists the altimeters approved for contest use

Thanks much to the NAR contest board and all of the fliers who helped get MicroPeak ready for this!

Posted Mon Feb 17 00:45:17 2014 Tags: rockets

AltOS 1.3.2 — Bug fixes and improved APRS support

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

AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.

This is a minor release of AltOS, including bug fixes for TeleMega, TeleMetrum v2.0 and AltosUI .

AltOS Firmware — GPS Satellite reporting and APRS improved

Firmware version 1.3.1 has a bug on TeleMega when it has data from more than 12 GPS satellites. This causes buffer overruns within the firmware. 1.3.2 limits the number of reported satellites to 12.

APRS now continues to send the last known good GPS position, and reports GPS lock status and number of sats in view in the APRS comment field, along with the battery and igniter voltages.

AltosUI — TeleMega GPS Satellite, GPS max height and Fire Igniters

AltosUI was crashing when TeleMega reported that it had data from more than 12 satellites. While the TeleMega firmware has been fixed to never do that, AltosUI also has a fix in case you fly a TeleMega board without updated firmware.

GPS max height is now displayed in the flight statistics. As the u-Blox GPS chips now provide accurate altitude information, we’ve added the maximum height as computed by GPS here.

Fire Igniters now uses the letters A through D to label the extra TeleMega pyro channels instead of the numbers 0-3.

Posted Sat Feb 15 02:45:39 2014 Tags: rockets

AltOS 1.3.1 — Bug fixes and improved APRS support

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

AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.

This is a minor release of AltOS, including bug fixes for TeleMega, TeleMetrum v2.0 and AltosUI .

AltOS Firmware — Antenna down fixed and APRS improved

Firmware version 1.3 has a bug in the support for operating the flight computer with the antenna facing downwards; the accelerometer calibration data would be incorrect. Furthermore, the accelerometer self-test routine would be confused if the flight computer were moved in the first second after power on. The firmware now simply re-tries the self-test several times.

I went out and bought a “real” APRS radio, the Yaesu FT1D to replace my venerable VX 7R. With this in hand, I changed our APRS support to use the compressed position format, which takes fewer bytes to send, offers increased resolution and includes altitude data. I took the altitude data out of the comment field and replaced that with battery and igniter voltages. This makes APRS reasonably useful in pad mode to monitor the state of the flight computer before boost.

Anyone with a TeleMega should update to the new firmware eventually, although there aren’t any critical bug fixes here, unless you’re trying to operate the device with the antenna pointing downwards.

AltosUI — TeleMega support and offline map loading improved.

I added all of the new TeleMega sensor data as possible elements in the graph. This lets you see roll rates and horizontal acceleration values for the whole flight. The ‘Fire Igniter’ dialog now lists all of the TeleMega extra pyro channels so you can play with those on the ground as well.

Our offline satellite images are downloaded from Google, but they restrict us to reading 50 images per minute. When we tried to download a 9x9 grid of images to save for later use on the flight line, Google would stop feeding us maps after the first 50. You’d have to poke the button a second time to try and fill in the missing images. We fixed this by just limiting how fast we load maps, and now we can reliably load an 11x11 grid of images.

Of course, there are also a few minor bug fixes, so it’s probably worth updating even if the above issues don’t affect you.

Posted Wed Jan 22 20:39:01 2014 Tags: rockets

AltOS 1.3 — TeleMega and EasyMini support

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

AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.

This is a major release of AltOS as it includes support for both of our brand new flight computers, TeleMega and EasyMini.

AltOS Firmware — New hardware, new features and fixes

Our new advanced flight computer, TeleMega, required a lot of new firmware features, including:

  • 9 DoF IMU (3 axis accelerometer, 3 axis gyroscope, 3 axis compass).

  • Orientation tracking using the gyroscopes (and quaternions, which are lots of fun!)

  • APRS support so your existing amateur radio receiver can track the location of your rocket.

  • Software FEC, both encoding and decoding.

  • Four fully-programmable pyro channels, in addition to the usual apogee and main channels.

  • STM32L CPU support. TeleMega needed a more powerful processor. The STM32L is a 32-bit ARM Cortex-M3 which is definitely up to the challenge.

Our new easy-to-use flight computer, EasyMini also uses a new processor, the LPC11U14, which is an ARM Cortex-M0 part.

For our existing cc1111 devices, there are some minor bug fixes for the flight software, so you should plan on re-flashing flight units at some point. However, there aren’t any incompatible changes, so you don’t have to do it all at once.

Bug fixes:

  • More USB fixes for Windows.

  • Turn off the cc1111 RC oscillator at startup. This may save a bit of power, and may reduce noise inside the chip a bit.

AltosUI — Redesigned for TeleMega and EasyMini support

AltosUI has also seen quite a bit of work for the 1.3 release, but almost all of that was a massive internal restructuring necessary to support flight computers with a wide range of sensors. From the user’s perspective, it’s pretty similar with a few changes:

  • Graphs can now show the raw barometric pressure

  • Support for TeleMega and EasyMini, including alternate TeleMega pyro channel configuration.

  • Bug fixes in how data were extracted from a flight record for graphing — sometimes values would end up getting plotted out of order, causing weird jaggy lines.

Posted Thu Dec 19 02:22:57 2013 Tags: rockets

Back on Black (Friday) Event

Altus Metrum is pleased to announce our “Back on Black (Friday)” event!

For the first time since the Black Forest fire in June, we’re re-opening our web store this weekend with a host of new and classic Altus Metrum products, including a special pre-order discount on our latest-and-greatest flight computer design, TeleMega.

This weekend only, Friday, 29 November 2013 through Monday, 2 December, 2013, the first 40 TeleMega direct orders placed through our web store will receive a special $50 pre-order discount (regular $400, now only $350!).

TeleMega is an advanced flight computer with 9-axis IMU, 6 pyro channels, uBlox Max 7Q GPS and 40mW telemetry system. We designed TeleMega to be the ideal flight computer for sustainers and other complex projects. TeleMega production is currently in process, and we expect to be ready to ship in mid-December. Pre-order now and we won’t charge you until we ship. Learn more about TeleMega at:

We are also pleased to announce that TeleBT is back in stock. Priced at $150, TeleBT is our latest ground station that connects to your laptop over USB or your Android device over BlueTooth. Learn more about TeleBT at

Another new product we’re thrilled to announce is EasyMini! Priced at only $80, EasyMini is a two-channel flight computer with built-in data logging and USB data download.

Like our more advanced flight computers, EasyMini is loaded with sophisticated electronics and firmware, designed to be very simple to use yet capable enough for high performance airframes. Perfect as a first flight computer, EasyMini is also great as a backup deployment controller in complext projects. Learn more about EasyMini at:

Also in stock for immediate shipment is MicroPeak, our 1.9 gram recording altimeter available for $50. The MicroPeak USB adapter, also $50, has been improved to make data downloading a snap. Read more about these at:

You can learn more about these and all our other Altus Metrum products at The special discount on TeleMega pre-orders is available only on orders placed directly through Bdale’s web store at

Thank you all for your support of Altus Metrum during 2013. It’s been a rough year, but we’re having a great time updating our existing products and designing new stuff! We look forward to returning products like TeleMetrum and TeleMini to the market soon, and plan to introduce even more new products soon.

Posted Thu Nov 28 22:02:50 2013 Tags: rockets

Tracking Orientation with Quaternions

I spent the flight back from china and the weekend adding orientation tracking to AltOS. I’d done a bit of research over the last year or so working out the technique, but there’s always a big step between reading about something and actually doing it. I know there are a pile of quaternion articles on the net, but I wanted to write down precisely what I did, mostly as a reminder to myself in the future when I need to go fix the code…

Quaternion Basics

Quaternions were invented by Sir William Rowan Hamilton around 1843. It seems to have started off as a purely theoretical piece of math, extending complex numbers from two dimensions to four by introducing two more roots of -1 and defining them to follow:

i² = j² = k² = ijk = -1

Use these new roots to create numbers with four real components, three of which are multiplied by our three roots:

r + ix + jy + kz

With a bit of algebra, you can figure out how to add and multiply these composite values, using the above definition to reduce and combine terms so that you end up with a set which is closed under the usual operations.

Then we add a few more definitions, like the conjugate:

q = (r + ix + jy + kz)
q* = (r - ix - jy - kz)

The norm:

| q | = ✓(qq*) = ✓(r² + x² + y² + z²)

‘u’ is a unit quaternion if its norm is one:

| u | = 1

Quaternions and Rotation

Ok, so we’ve got a cute little 4-dimensional algebra. How does this help with our rotation problem? Let’s figure out how to rotate a point in space by an arbitrary rotation, defined by an axis of rotation and an amount in radians.

First, take a vector, ‘v’, and construct a quaternion, ‘q’ as follows:

q = 0 + ivx + jvy + kvz

Now, take a unit quaternion ‘u’, which represents a vector in the above form along the axis of rotation, and a rotation amount, ω, and construct a quaternion ‘r’ as follows:

r = cos ω/2 + u sin ω/2

With a pile of algebra, you can show that the rotation of ‘q’ by ‘r’ is:

q° = r q r*

In addition, if you have two rotations, ‘s’ and ‘r’, then the composite rotation, ‘t’, a rotation by ‘r’ followed by ‘s’ can be computed with:

q°° = s (r q r*) s*

    = (sr) q (r*s*)

    = (sr) q (sr)*

t   = s r

q°° = t q t*

That’s a whole lot simpler than carrying around a 3x3 matrix to do the rotation, which makes sense as a matrix representation of a rotation has a bunch of redundant information, and it avoids a pile of problems if you try to represent the motion as three separate axial rotations performed in sequence.

Computing an initial rotation

Ok, so the rocket is sitting on the pad, and it’s tilted slightly. I need to compute the initial rotation quaternion based on the accelerometer readings which provide a vector, ‘g’ pointing up. Essentially, I want to compute the rotation that would take ‘g’ and make it point straight down. Construct a vector ‘v’, which does point straight up:

g = (0, ax, ay, az) / norm(0, ax, ay, az)
v = (0, 0, 0, 1)

G is ‘normalized’ so that it is also a unit vector. The cross product between g and v will be a vector normal to both, which is the axis of rotation. As both g and v are unit vectors, the length of their cross product will be sin ω

a = g × v

  = u sin ω

The angle between g and v is the dot product of the two vectors, divided by the length of both. As both g and v are unit vectors, the product of their lengths is one, so we have

cos ω = g · v

For our quaternion, we need cos ω/2 and sin ω/2 which we can get from the half-angle formulae:

cos ω/2 = ✓((1 + cos ω)/2)
sin ω/2 = ✓((1 - cos ω)/2)

Now we construct our quaternion by factoring out sin ω from the ‘a’ and:

q = cos ω/2 + u sin ω sin ω/2 / sin ω

Updating the rotation based on gyro readings

The gyro sensor reports the rate of rotation along all three axes, to compute the change in rotation, we take the instantaneous sensor value and multiply it by the time since the last reading and divide by two (because we want half angles for our quaternions). With the three half angles, (x,y,z), we can compute a composite rotation quaternion:

   cos x cos y cos z + sin x sin y sin z +
i (sin x cos y cos z - cos x sin y sin z) +
j (cos x sin y cos z + sin x cos y sin z) +
k (cos x cos y sin z - sin x sin y cos z)

Now we combine this with the previous rotation to construct our current rotation.

Doing this faster

If we read our sensor fast enough that the angles were a small fraction of a radian, then we could take advantage of this approximation:

sin x ≃ x
cos x ≃ 1

that simplifies the above computation considerably:

1 + xyz + i (x - yz) + j (y + xz) + k (z - xy)

And, as x, y, z « 1, we can further simplify by dropping the quadratic and cubic elements as insignificant:

1 + ix + jy + kz

This works at our 100Hz sampling rate when the rotation rates are modest, but quick motions will introduce a bunch of error. Given that we’ve got plenty of CPU for this task, there’s no reason to use this simpler model. If we did crank up the sensor rate a bunch, we might reconsider.

Computing the Current Orientation

We have a rotation quaternion which maps the flight frame back to the ground frame. To compute the angle from vertical, we simply take a vector in flight frame along the path of flight (0, 0, 0, 1) and rotate that back to the ground frame:

g = r (0 0 0 1) r*

That will be a unit vector in ground frame pointing along the axis of the rocket. The arc-cosine of the Z element will be the angle from vertical.


All of the above code is checked into the AltOS git repository

I added a test mode to the firmware that just dumps out the current orientation over the USB link which lets you play with rotating the board to see how well the system tracks the current orientation. There’s a bit of gyro drift, as you’d expect, but overall, the system tracks the current orientation within less than a tenth of a degree per second.

Even with all of this computation added, the whole flight software is consuming less than 7% of the STM32L CPU time.

Posted Mon Oct 28 15:57:27 2013 Tags: rockets

Altimeter Testing at Airfest

Bdale and I, along with AJ Towns and Mike Beattie, spent last weekend in Argonia, Kansas, flying rockets with our Kloudbusters friends at Airfest 19. We had a great time! AJ and Mike both arrived a week early at Bdale’s to build L3 project airframes, and both flew successful cert flights at Airfest!

Airfest was an opportunity for us to test fly prototypes of new flight electronics Bdale and I have spent the last few weeks developing, and I thought I’d take a few minutes today to write some notes about what we built and flew.


We’ve been working on TeleMega for quite a while. It’s a huge step up in complexity from our original TeleMetrum, as it has a raft of external sensors and six pyro circuits.

Bdale flew TeleMega in his new fiberglass 4” airframe on a Loki 75mm blue M demo motor. GPS tracking was excellent; you can see here that GPS altitude tracked the barometric sensor timing exactly:

GPS lost lock when the motor lit, but about 3 seconds after motor burnout, it re-acquired the satellite signals and was reporting usable altitude data right away.

The GPS reported altitude was higher than the baro sensor, but that can be explained by our approximation of an atmospheric model used to convert pressure into altitude.

The rest of the flight was also nominal; TeleMega deployed drogue and main chutes just fine.


We’ve redesigned TeleMetrum. The new version uses better sensors (MS5607 baro sensor, MMA6555 accelerometer) and a higher power radio (CC1120 40mW). The board is the same size, all the connectors are in the same places so it’s a drop-in replacement, and it’s still got two pyro channels and USB for configuration, data download and battery charging.

I loaded up my Candy-Cane airframe with a small 5 grain 38mm CTI classic:

The flight computer worked perfectly, but GPS reception was not as good as we’d like to see:

Given how well TeleMega was receiving GPS signals, I’m hopeful that we’ll be able to tweak TeleMetrum to improve performance.


We’ve also redesigned TeleMini. It’s still a two-channel flight computer with logging and telemetry, but we’ve replaced the baro sensor with the MS5607, added on-board flash for increased logging space and added on-board screw terminals for an external battery and power switch. You can still use one of our 3.7V batteries, but you can also use another battery providing from 3.7 to 15V.

I was hoping to finish up the firmware and fly it, but I ran out of time before the launch. The good news is that all of the components of the board have been tested and work correctly, and the firmware is ‘feature complete’, meaning we’ve gotten all of the features coded, it’s just not quite working yet.


EasyMini is a new product for us. It’s essentially the same as a TeleMini, but without a radio. Two channels, baro-only, with logging. Like TeleMini, it includes an on-board USB connector and can use either one of our 3.7V batteries, or an external battery from 3.7V to 15V. EasyMini and TeleMini are the same size, and have holes in the same places, so you can swap between them easily.

I flew EasyMini in my Koala airframe with a 29mm 3 grain CTI blue-streak motor. EasyMini successfully deployed the main chute and logged flight data:

We also sent a couple of boards home with Kevin Trojanowski and Greg Rothman for them to play with.


TeleGPS is a GPS tracker, incorporating a u-blox Max receiver and a 70cm transmitter. It can send position information via APRS or our usual digital telemetry formats.

I was also hoping to have the TeleGPS firmware working, and I spent a couple of nights in the motel coding, but didn’t manage to finish up. So, no data from this board either.

Production Plans

Given the success of the latest TeleMega prototype, we’re hoping to have it into production first. We’ll do some more RF testing on the bench with the boards to make sure it meets our standards before sending it out for the first production run. The goal is to have TeleMega ready to sell by the end of October.

TeleMetrum clearly needs work on the layout to improve GPS RF performance. With the testing equipment that Bdale is in the midst of re-acquiring, it should be possible to finish this up fairly soon. However, the flight firmware looks great, so we’re hoping to get these done in time to sell by the end of November.

TeleMini is looking great from a hardware perspective, but the firmware needs work. Once the firmware is running, we’ll need to make enough test flights to shake out any remaining issues before moving forward with it.

EasyMini is also looking finished; I’ve got a stack of prototypes and will be getting people to fly them at my local launch in another couple of weeks. The plan here is to build a small batch by hand and get them into the store once we’re finished testing, using those to gauge interest before we pay for a larger production run.

Posted Wed Sep 4 17:19:16 2013 Tags: rockets

Choosing Embedded Processors for AltOS

When Bdale and I started building rocketry hardware together, we had already picked out a target processor, the TI cc1111. We picked that chip almost entirely based on the digital transceiver that is built in to the chip, and not because we had any particular love for the 8051 microcontroller. At that time, I’d seen people struggle with PIC processors, battle AVR to a draw and spend a lot of time trying to get various ARM processors running. So, the 8051 didn’t seem all that far from normal, and the cc1111 implementation of it is pretty reasonable, including credible USB support and a built-in DMA engine.

Since those early days, we’ve gone on to build boards with a slightly wider range of processors:

  • TI cc1111
  • Atmel ATmega32U4
  • Atmel ATiny85
  • STMicroelectronics STM32L151/STM32L152
  • NXP LPC11U14

Bdale thinks we should reduce the number of components we use to focus our efforts better. He’s probably right, but I have to admit that I’ve had way too much fun getting each of these chips running.

I thought I’d spend a bit of time describing our general process for selecting a new CPU.

  • Free software. I’m long past the age at which I trust hardware vendors to deliver credible binary software. If you want me to use your silicon, make sure the tools required to use it are all free software.

  • Debian support required. Bdale and I do everything on Debian, so any processor we use needs to have tools that run under Debian. We’re more than willing to package software for Debian, so if it’s just generic Linux-compatible free software, that’s fine.

  • Built-in USB. Everything we build needs to talk to a computer for configuration and data download. Don’t even think of asking me to attach another chip for USB support. Ok, so the ATtiny85 doesn’t qualify here, and that project does use an external chip for USB which is connected to the ATtiny85 through an LED and phototransistor. I was excited when TI came out with the CC340 chips because the MSP430 is a much nicer CPU than the 8051. But, they still haven’t added USB. If I’m going to add another chip for USB, it’ll be a CPU anyways, at which point I’ll use a stand-alone RF chip.

  • Cheap developer boards. TI sells a tiny little cc1111 developer board; STmicroelectronics and NXP both sell boards that include a programmer and a target CPU for prototyping software. And, there are a million “Arduino” clones with various Atmel processors on them. Cheap means I can buy them without thinking too hard; having a built-in programmer means that early OS development can be done without first having to figure out how to wire up a programmer.

  • Probably 32 bits, probably an ARM. Yeah, the cc1111 and Atmel processors were fun to bring up, but I’m pretty much over the 8-bit microcontroller now. ARM processors are far more sophisticated in terms of power management and built-in device capability, plus they’re a ton faster at doing any math. The ATtiny85 remains an exception here; it’s smaller than any ARM I can get, and so it’s still useful for projects too small for an ARM.

  • Available in small quantities from a reasonable on-line retailer like Digikey, Mouser or even Avnet Express. I’d love to try out the new low-cost STM32L100 parts, but the only one available is the largest one in the 64LQFP package, and I really don’t need that many pins for most products.

CC1111 involved a lot of software hacking

The 8051 processor in the CC1111 is very well documented, including the two-wire debugging interface. What was missing was a canned solution for programming and debugging the chip from Debian. However, with sufficient motivation and accurate docs, I was able to create a programmer from a USB device with a couple of GPIOs and a lot of ugly software on Linux. That sufficed to get the USB stack limping along, at which point I wrote a much faster programmer that ran on the cc1111 itself and could program another cc1111.

With that, I created an assembly-level debugger that could be hooked to the existing SDCC source level debugger and had a full source-level debugging environment for the 8051. This turned out to be way better than what I could get on the Atmel processors, where I’ve got a program loader and a whole lot of printf debugging.

STM has been great

The STM32L-Discovery board has a standard STM debugging setup for the Cortex SWD interface right on the same board as a target CPU. That made for completely self-contained development, with no jumper wires (a first for me, for sure). There’s free software, stlink which can talk over the debugger USB connection to drive the SWD interface. This is sufficient to flash and debug applications using GDB.

Of course, GCC supports ARM quite well; the only hard part was figuring out what to do for a C library. I settled on pdclib, which is at least easy to understand, if not highly optimized for ARM.

We’ve built a ton of boards with the STM32L151 and STM32L152; at this point I’m pretty darn comfortable with the architecture and our tool chain.

Adventures with NXP

The NXP LPC11U14 is a very different beast. I’m using this because:

  • It’s small (5mm x 5mm)

  • It’s cheap ($1.48 q100)

The LPCXpresso board looks much like the STM32L-Discovery, with a debugger interface wired to the CPU directly on the board. However, I haven’t found free software tools to drive this programmer; all I’ve found are binary-only tools from NXP. No thanks.

Fortunately, the LPC11U14 uses exactly the same SWD interface as the STM32L, so I was able to sever the link between the programmer and the target on the LPCXpresso board and hook the target to an ST-Link device (either the one on the STM32L-Discovery board, or the new stand-along programming dongle I bought). With that, I wrote an openocd script to talk to the LPC11U14 and was in business.

What I found in the NXP processor was a bit disturbing though — there’s a mask ROM that contains a boot loader, which always runs when the chip starts, and a bunch of utility code, including the only documented interface to programming the flash memory. I cannot fathom why anyone thought this was a good idea — I don’t want a BIOS in my embedded CPU, thankyouverymuch; I’d really like my code to be the first instructions executed by the CPU. And, any embedded developer is more than capable of programming flash using a register specification, and calling some random embedded code in ROM from the middle of my operating system is more than a bit scary.

NXP could do two simple things to make me like their parts a whole lot more:

  • Publish the programmer source code. The programming dongle is a tool for selling your silicon, not a separate revenue stream. Publish the source under a free software license (GPL recommended, of course). We’ll take it, make it better, and ensure that you get the changes back to help your other customers. It’s a win-win plan.

  • Document the flash programming registers. Yeah, I could probably disassemble the mask-rom bits that are on the chip, but I have better things to do with my time. Heck, go wild and document any other hidden bits in the silicon. Again, we’re embedded developers, we don’t like magic hardware hidden from view any more than PC developers like the BIOS and SMM.

Right now, I’m hoping the STM32L100C6 parts become available in small quantities so I can try them out; they promise to be as cheap as the LPC11U14, but are better supported by free software and offer more complete hardware documentation. Yeah, they’re a bit larger; that will probably be annoying.

Posted Wed Aug 7 15:35:39 2013 Tags: rockets

AltOS 1.2.1 — TeleBT support, bug fixes and new AltosUI features

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

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

The biggest new feature for AltOS is the addition of support for TeleBT, our ground station designed to operate with Android phones and tablets. In addition, there’s a change in the TeleDongle radio configuration that should improve range, some other minor bug fixes and new features in AltosUI

AltOS Firmware — Features and fixes

There are bug fixes in both ground station and flight software, so you should plan on re-flashing both units at some point. However, there aren’t any incompatible changes, so you don’t have to do it all at once.

New features:

  • TeleBT support.

  • Improved radio sensitivity. The TeleDongle receiver parameters have been tweaked to provide better reception.

  • TeleMini now completely resets all radio parameters in recovery mode (with the two outer debug pins connected) — 434.550MHz, N0CALL, factory radio cal.

Bug fixes:

  • USB device fixes. This improves operation with Windows, avoiding hangs and errors in many cases.

  • Correct the Kalman filter error covariance matrix; the old parameters were built assuming continuous measurements.

AltosUI — Easier to use

AltosUI has also seen quite a bit of work for the 1.2.1 release. It’s got several fun new features and a few bug fixes.

New Graph UI features:

  • Show tool-tips with the value near the cursor.

  • Make the set of displayed values configurable. Add all of the available data values just in case you want to see them.

  • Added a Map tab showing the ground track of the whole flight.

  • The flight summary tab now includes the final GPS position. This lets you figure out where your rocket landed without replaying the whole flight.

Other new AltosUI features:

  • TeleBT support, including Bluetooth connections (Linux-only, at present).

  • Shows the callsign in the Monitor Idle and other command-mode windows so that you can tell what callsign is being used.

  • Show the block number when downloading flight data. This lets you see something happen even for longer flights.

  • Make the initial position of the AltosUI configurable so that you can position it out of the way of the rest of you desktop.

  • Distribute Mac OS X in .dmg format (Mac OS Disk Image); this means you don’t need to explicitly unpack the bits.

Bug fixes:

  • Deal with broken networking while downloading map tiles. Tiles are now always downloaded asynchronously so that the UI doesn’t freeze when the network is slow.

Posted Tue May 21 17:47:09 2013 Tags: rockets