Saturday, December 17, 2011

The amazing flight of K6RPT-11


This was about 3 days ago. The California Near Space Project (CNSP) team launched 4 balloons. Two of them were short-duration, high-altitude flights. The other two were long-duration floaters (K6RPT-11 and K6RPT-12). First, the announcement:


Our goal is to reach neutral buoyancy at a very high altitude and fly as far across the United States as possible.


The balloon not only made it through north america. It completely crossed the Atlantic, entered Spain through Jerez de la Frontera and exited towards Italy. After a 57 hours flight, it eventually descended on the Mediterranean sea off the coast of Algeria.

Captura de pantalla 2011 12 16 a las 09 33 40

Look at the green portion of the trajectory after the balloon passed New Jersey. These were quiet hours of uncertainty until the signal was picked up again from the Azores:

Captura de pantalla 2011 12 16 a las 09 35 37

Launch time was 2011-12-12 00:40:31z. The last packet was heard on 2011-12-14 09:46:30z:

Captura de pantalla 2011 12 16 a las 09 34 29

You can see the full trajectory on while it's recent:

Update: Below is a video of the launch:


Sunday, September 25, 2011


¡Gracias a todos los asistentes a mi charla sobre fotografía espacial en la conferencia OSHWCON 2011 y sobre todo a los organizadores por darme la oportunidad de exponer el proyecto! Espero que se repita y nos podemos ver con más proyectos el año que viene. Para cualquier duda me podéis localizar en el correo javi en trackuino punto org. ¡Un saludo!

(ENG: Thanks to all who attended my talk at OSHWCON 2011 and especially to the organizers for the opportunity to present my project! Keep it up and hope we'll see more projects coming next year!)

Tuesday, August 2, 2011

Important fix in version 1.31

Version 1.3 of the Trackuino firmware had a bug by which altitudes over 32767 feet would be rolled over to negative values. A new version fixing this issue is available in the downloads area. No extra features have been added, so your "config.h" from previous version 1.3 can be reutilized verbatim.


Saturday, July 30, 2011

How NOT to launch a balloon

The neck snapped when the balloon turned upside down. We were planning to release the load line slowly so that the strings would not rip through the payload box, completely oblivious that the weakest point was the neck of the balloon :(

Tuesday, July 5, 2011

Trackuino Shield

This is really exciting! Kyle Crockett has designed a new Trackuino shield. Just plug it on top of an Arduino board to turn it into an APRS tracker complete with GPS, a Radiometrix HX1 FM transmitter and a temperature sensor!

The whole thing is powered through the Arduino jack (7-12V), and the only external components needed are the GPS and radio antennas. The total footprint is much smaller than the previous board, so its price is also cut by more than half. And because all the Atmega pins are broken out to female headers, It can be easily extended by stacking more shields on top of it.

For now, you'll have to figure out the bill of materials from the Eagle schematic, but we'll post a proper BOM shortly. The SCH and BRD files can be downloaded from the project page.

Monday, July 4, 2011

Version 1.3 of the firmware is up!

Trackuino logoVersion 1.3 of of the Trackuino firmware is up in the downloads area! There are lots of improvements and fixes. Here is a summary:

Improved GPS compatibility

The previous GPS code made too many risky assumptions about the NMEA format, so it failed miserably on certain versions of the Venus 634FLPx (which, ironically, was the only supported GPS). Now the parsing routines are more tolerant to variations in the numeric formats, so compatibility with other units should be greater.

Signal quality (enter real-time computing)

In Packet Radio, the maximum bandwidth used by the AFSK carrier is 2,200 Hz. Nyquist tells us that we need at least 4,400 samples per second to properly rebuild the signal at the receiver, but that requires an ideal low-pass filter with a cutoff frequency of 2,200 Hz, which is neither physically achievable nor realistic in FM radios where the cutoff is usually higher, around 3,000 Hz. For those two reasons, oversampling is usually desirable (even if not mathematically necessary) if we want to avoid annoying harmonics that distort the signal and waste our scarce power.

The Trackuino firmware uses a 62,500 KHz sample rate, which is well away from the audible spectrum. Oversampling improves the quality of the signal at the receiver, but it requires pushing samples at a rate of 1 sample every 256 clock cycles (16 MHz clock rate / 256 = 62.5 KHz), so it's really taxing on the CPU. To make things worse, the Arduino is also busy doing a lot of equally important things, such as staying up to date with the GPS, keeping track of time so that millis() and delay() keep working as expected, and handling the buzzer (more on the buzzer later). All these tasks are interrupt-driven, which means they happen asynchronously without regard of one another or the normal program flow. The interrupts can be queued, but only one of each kind at a time. If an interrupt comes without having served the previous one, the second interrupt will be lost. So, not only has our modulator a meager 256 cycles to do its job, but it also has to struggle over the CPU with other interrupts...   When some task needs to be done under a deadline constraint such as this, it's called a real-time system. Efforts to ensure real-time operation are geared towards three goals:

  1. Priorizing the real-time task over not-so-important tasks. In the AVR architecture, interrupt priorities are fixed, so we can't do that.
  2. Keeping our real-time task short, so that it can meet its deadline.
  3. Keeping non-important tasks short, so that they don't hog the CPU while the important task is waiting.

There are a number of improvements in version 1.3 on those regards:

  • Serial (GPS) interrupt: The selfish implementation of this interrupt in the Arduino library spent an abusive 330 cycles on every received byte. It means that, for every received character from the GPS, chances are that one modem interrupt is lost altogether. Arduino version 22 has an optimization that cuts this time down to 80 cycles, so the code now enforces compilation under Arduino version 22 or later.
  • Modem interrupt: Some optimizations have been done to shave off a few cycles here and there. The modem interrupt should take 150 cycles max, average is less than that.
  • Debug information: By uncommenting a flag in config.h you can get useful information on overrun conditions.

Previous versions of had interrupt overrun issues, which translated into small variations from the nominal baud rate (1200 bps). Luckily receivers have some tolerance to baud rate deviations, so it's not that big a deal. In any case, the new version should improve the rate of successfully decoded packets.

SRAM usage optimization

The Atmega328P has 2 KB of SRAM, of which about 512 bytes were taken up by a huge sine table in modem.cpp. This table has been moved to the much more spacious program memory (32 KB). There are a few other candidates that scream to be moved to PROGMEM too, such as the APRS comment, callsigns and such, but these haven't been moved (yet).

Buzzer support

This should help in acoustically locating the payload. The buzzer is handled by timer 1 using PWM. Piezoelectric buzzers demand very little current, so they can be driven directly with pins 9 or 10. The tone frequency can be configured in config.h as well as the duty cycle in seconds. It doesn't make sense to have a payload beeping at 100,000 ft. since there is no air to begin with, so the maximum operating altitude can also be programmed.

CPU usage LED indication

This might look just cosmetic or geeky, but it's actually quite useful. The idea is that the LED will glow increasingly brighter as the CPU gets busier. For example:

  • If the AVR is idle, the light will be very dim. Tthe AVR is never really idle for long periods of time, since timers 0 (millis) and 1 (buzzer) are going off periodically.
  • When receiving data on the serial port, the LED will turn slightly brighter because it takes extra CPU to process the incoming bytes. This is a way of checking for GPS activity at a glance.
  • APRS transmission takes the most CPU, so the LED will be almost fully bright.

Monday, June 27, 2011

Intervalometer with CHDK

I wrote a script for Canon cameras with CHDK that works as an intervalometer. The script can take photos and videos alternately. The interval between photos, the number of pictures between videos, and the length of the videos in seconds can all be configured from the CHDK interface. It has other handy features like switching the LCD off to save power, or pre-focusing at the infinity so that the AF doesn't have to struggle with low contrast exposures at high altitudes.

CHDK is a firmware addition that enhances the camera functionality by giving more control over exposure, raw capture and display options, but most importantly for us, it allows scripted control of the camera. The scripts can be written in a derivative of BASIC called uBASIC, or Lua. You can control almost every aspect of the camera from a script, including filesystem manipulation, timed shooting, adjusting the flash or the exposure parameters, timed shots and even switching dial modes programatically. It's perfect for high altitude balloons because the camera can operate autonomously without any extra circuitry and does not require any attention from the tracker. Check out their web page for installation details. The firmware is fully reversible, you can remove CHDK by just reformatting the SD card and the camera will be back to normal.

The intervalometer script works quite nicely! I went to a fireworks display earlier today and captured 390 photos about 0.5 seconds apart from one another. The camera I used is a Canon A570IS set to manual mode, 0.4 seconds exposure, f/2.6 aperture, ISO 100, no zoom and pre-focused at the infinity with the intervalometer script. I assembled all the pictures together in a sort of time-lapse video and here is the result:

More on the intervalometer at the trackuino project's wiki. You can download the script (trackuino.lua) from the downloads area.

The script is largely based on CHDK's Accurate intervalometer with power saving and pre-focus and the Spacebits team's intervalometer. Most of the code is actually taken from them. I tried to make it compatible with other Digic III/IV cameras, but If the trackuino intervalometer doesn't work for you, make sure you check these out!

Monday, April 18, 2011

KJ6KUV-11 flight and successful recovery!

KJ6KUV-11 was launched yesterday from Ojai, California at 0820 PDT and successfully recovered 84 minutes later near Oak Park, 53.6 Km to the south-east! Check Kyle's blog for details, but I think all the efforts can be summarized with one single picture:


During the whole flight, the balloon was able to steadily report its position via APRS and the trajectory could be followed at Between 12-16 Km altitude, the balloon caught the jet stream and sped up quite a lot as you can tell by the more spread-out points on the map!

kj6kuv-11 trajectory

The tracker was a Trackuino board with a Venus 634FLPx GPS and a Radiometrix HX1 300 mW radio transmitter. We were not sure the HX1 was going to deliver enough power to reach any digipeater from that high up. Well, sure it did... At its peak altitude (20 Km), the signal could be heard from Phoenix, Arizona, which is... 597 Km away!

kj6kuv-11 hx1 range

We were also not sure the Venus 634FLPx would report its position above 18 Km high, since many manufacturers seem to get the CoCom limits all wrong. But then again, the above picture proves how the GPS worked perfectly at 20036 meters.

Here are some flight stats I gathered with WBALTRAK. This is a plot of altitude versus time:

kj6kuv-11 altitude vs time

The ascent rate was smooth and constant at about 500 meters/minute. After the balloon popped, the payload fell at a vertiginous 1000 meters/min and steadily slowed down as the air density allowed the parachute to deploy. The payload landed smoothly at 294 meters/min:

kj6kuv-11 vertical rates

The speed was about 38 Km/h average and it reached peaks of 100 Km/h (about 60 mph) while the balloon was caught by the jet stream:

kj6kuv-11 speed

This was a lot of fun to track :)


Saturday, April 9, 2011

First Flight

I'm really excited to announce that Kyle (KJ6KUV), a great contributor to this project, is launching a balloon and he'll be using a Trackuino board to track its payload. He'll be launching from the Oxnard airport (California) on sunday april 17 around 8:00 am pacific time.

To track the balloon online go to this page. It will have the most recent position as well as the previous positions reported:

Best of luck with the chase!

4 things

A few random updates:

1. I'll be giving a speed talk on Trackuino, high altitude balloons and near space photography at OSHWCON 2011! Quoting their web site:

The Open Source Hardware, Electronics and Robotics Convention is a 3-day event organized by the Synusia collective in an effort to extend the Open Source Software and to promote electronics and the philosophy of "do it yourself". The event will take place in Madrid at the Centro de Formación Padre Piquer,  from the 23 to 25 September 2011.

2. This blog is becoming a bit chaotic, with bits of information here and there. So, I'm giving the Trackuino project's site a facelift. From now on, technical articles will go to the wiki, while news and event updates will stay in this blog.

3. Even though the wiki is pretty much empty right now, I just posted an article on flight prediction based on Rick von Glahn (NØKKZ) great WBALTRAK software. Unlike on-line prediction sites, this program uses actual inflight data to predict the touchdown point with higher accuracy. Check it out, I think flight prediction is a key step prior to and during the flight of high altitude balloons!

4. Last, but not least, we're having our first Trackuino flight next sunday! But this deserves a dedicated post, so stay tuned!


Saturday, January 8, 2011

How to build your own Trackuino board

Update: the latest information on building the Trackuino board (with slight variations from the process described here) is on the google code project's main page.

Here is how to build your own DYI tracker solution based on the Trackuino firmware and Kyle's PCB. Building the tracker involves a bit of hackery at some points, but I'll try to make it as straight-forward as possible. This is how the finished board looks like:



This is a summary of older posts, in case you just landed:

  • GPS: Venus 634FLPx. Supports > 18 Km according to their tech support (to be confirmed empirically)
  • Radio: The board supports Radiometrix's HX1 (300 mW) as well as Argentdata's MX146-8v (500 mw).
  • 1200 bauds AFSK using 8-bit PWM
  • Sends out standard APRS position messages (latitude, longitude, altitude, course, speed and time).
  • Internal/external temperature sensors (LM60) to read temperature in and outside the payload
  • Support for 1 capacitive humidity sensor
  • Cut-down "aka suicide" mechanism: you can hook up a nicrom wire and cut the payload line if your balloon gets stuck aloft for a long time.
  • ICSP header for in-circuit programming
  • 2 x SMA female plugs (1 x GPS in + 1 x radio out)
  • Open source (GPLv2 license), both software and hardware. In other words, do whatever you want with it: modify it, add it to your project, etc. as long as you opensource your modifications as well.

Which radio to pick?


Radiometrix's HX1 is cheaper, but Argentdata's MX146-8V is more powerful and thus has a better range. On the other hand, the HX1 version requires fewer components to buy and solder. My take? The HX1 is good enough.

How to build the board?

Both Eagle's schematic and PCB source files are here. You can do the exposure/development/etching process yourself, but I suggest sending it to a PCB house. I made the project public at BatchPCB, so anyone can go and order one. Their prices are not bad, but please comment if you find a better deal.


Here is the bill of materials for the HX1 version and the MX146 version. See what I mean about the HX1 requiring fewer components? Also, these parts are in the schematic, but haven't found a clear purpose for them yet, so don't buy them.

How to build the firmware?

The easiest way is with the Arduino IDE. Download the latest "" from here. Unzip it in your sketches directory.

Now, you'll have to change some settings. Open the "config.h" tab and:

  • Put your own callsign and SSID here. By default it's nonsense, something like "MYCALL". SSID 11 is good for balloons.
  • Select your type of radio here (HX1 or MX146)
  • Optionally, add some custom comment to the APRS messages, set a different TXDELAY, change the APRS update period (default = 61 seconds), etc.

Now open the trackuino.pde sketch, compile and flash.

If you're comfortable with command line tools, there is also a "trackuino-gcc-xxxxxxxx.tgz" version with Makefiles that you can compile with the gcc-avr toolchain. I like to develop using the gcc-avr toolchain because the IDE doesn't support multi-file projects quite well.


Time to test the board! Plug the GPS and TX antennas and power the board. You need at least 6 volts for the HX1 version, and 9 volts for the MX146 version.

I have tested the HX1 version. If someone tries with the MX146, feedback will be very welcome!

And since a picture is worth a thousand words, take a look at this screenshot from APRS.FI and see how far this little HX1 can get. I'm successfully being digipeated by EA5ERC-15, which is an unbelievable 144.5 kilometers away! And I'm at sea level!

Captura de pantalla 2011-01-08 a las 20.29.54.png


Thoughts on on-line collaboration

On my last entry, I blogged about a schematic diagram to help those DIYers build their own tracker using the Trackuino firmware. Well, Kyle Crockett picked it up and generously built a nice PCB out of it. It blows me away how we're alive during the time when you can post the most vertical stuff on-line, reach out to those with the same interests as you, and find people across the globe willing to collaborate towards the same goal without ever having met in person... It really does.


I'll be posting soon with details on how to get one of these boards manufactured and the bill of materials so that you can assemble it yourself.