How to install wgrib2 in OSX

Prompted by both my own struggles with wgrib2 compilation and a plea on the rNOMADS email listserv, I’m going to describe how to compile and install wgrib2 on Mac OS.

First of all, some background: wgrib2 is an excellent utility written by Wesley Ebisuzaki at NOAA.  It allows for a number of swift and stable operations on GRIB2 files (a common file format for weather and climate data).  It is also a requirement for using grib files in rNOMADS (the function ReadGrib() in particular).

So here’s how to install it on Mac OS.

  1.  Get Command Line Tools for Xcode (search for it on Duckduckgo or your engine of choice) and also make sure gcc is installed. If you don’t know what gcc is, stop now and find someone who does (it will save you a lot of time).
  2. Download wgrib2 here (note download links are pretty far down the page).
  3. Untar the tarball somewhere, and roll up your sleeves.  cd into the resulting wgrib directory.
  4.  In the makefile, uncomment the lines

    #export cc=gcc
    #export FC=gfortran
    Also search for makefile.darwin in the makefile and uncomment the line containing it.  You’ll see instructions to this effect in the makefile anyway.
  5. Now we have to edit the included libpng package, since it is untarred by the makefile and doesn’t inherit our compiler specifications in step 4. Ensuring that we’re in the wgrib directory:

    tar -xvf libpng-1.2.57.tar.gz
    cd libpng-1.2.57/scripts/

    now edit the makefile.darwin file, changing




    Now, return to the wgrib directory, and re-tar libpng!

    tar -cf libpng-1.2.57.tar libpng-1.2.57
    gzip libpng-1.2.57.tar

    If it asks you if you want to replace the original tar.gz file, say “yes”.  What we’ve done here is edited libpng to make sure it uses the right compiler.
  6. Finally, type make to build wgrib2.

If you are still having problems (for example, libaec complaining that there is no c compiler), make sure that all the compiler commands (gcc, cc, etc.) all point to something other than clang (the default compiler that comes with OSX).  You may have to edit your bash_profile file to ensure this.

As always, contact me on the form below if you’re having unresolvable issues.

Instruments for High-Altitude Balloons

For many of us, an important motivation of launching balloons high in the atmosphere is to put instruments up there. Of course, the fact that instruments are heavier than air means they resist attempts to get them in the atmosphere and are prone to falling out of it. So, airborne sensors need to be light enough to be lifted by an affordable balloon and cheap enough to make risk of crash acceptable. I spent a big chunk of the last couple years designing and building a custom instrument with these characteristics in mind; this post describes how I did it.

My particular field is infrasound, sound waves whose pitch is too low for humans to hear. Infrasound waves normally come from very large sources like lightning, volcanoes, nuclear bomb tests, windmills, and even large animals like tigers or elephants. Unlike audible sound, infrasound waves can propagate long distances without dissipating as heat, which makes them useful for monitoring nuclear and volcanic blasts. Putting microphones high in the air could help improve geographic coverage in our otherwise land-based monitoring networks.

Solar balloons offer an affordable and flexible means of putting cheap, lightweight sensors in the sky. However, commercial infrasound instrumentation falls short in those aspects. To be sure, we do have a few high-quality data loggers and sensors to choose from, but none is lightweight or cheap enough to fly on solar balloons. The closest is the Omnirecs DATACUBE-3 (below, right). Including batteries and sensor, it weighs more than 1 kg and can cost a few thousand USD (depending on quantity and options chosen).

My normal research is on volcano acoustics. I’m not normally worrying about flying microphones on balloons, but I faced similar instrument limitations in volcano fieldwork. For example, my most recent project involved a hike with 2000 m of elevation gain to install 17 instruments near the vent of Tungurahua volcano. On a hike like that, the last thing I need is to be weighed down with heavy instruments, or even heavy batteries for the instruments. Plus, the instruments near the vent are definitely in harm’s way, and I don’t want to accidentally blow up an expensive sensor.


The upper slopes of Tungurahua: loose, rocky, steep, and prone to ballistic fall during eruptions.

The answer was that I needed to design my own instrument. This process had two parts: firmware (programming the microcontroller) and hardware (finding the right components and connecting them together). Fortunately for me, I began this project around 2012-2013 when a revival in hobbyist electronics was in full swing, and had access to components that are powerful but still novice-friendly.


The various companies and online forums I used to design the instrument. Most of these cater to hobbyists and beginners.

The Arduino system makes firmware way easier than it used to be. Arduino is a combination of a microcontroller (very, very basic computer), user-friendly circuit board, and programming interface that makes it easy for hobbyists to program the microcontroller and connect peripherals to it. It’s perfect for a beginner. In my case, the firmware’s job was to read data from several inputs, do a little processing, and write output data to a micro SD card. Inputs included an analog-digital converter listening to the infrasound microphone, a GPS (for precise timing and location), a temperature sensor, and a battery voltage tracker.


The Arduino IDE speeds up the process of writing and testing code.

Without the Arduino system to simplify this process, it wouldn’t really be accessible to someone like me. I’m a geophysicist, not an electrical engineer! But it still wasn’t easy, and it took me a couple years of off-and-on work before I really got it working well.

The hardware part of this project began with a bunch of user-friendly breakout boards wired to the Arduino. A breakout board is a little circuit board that includes some principal component (say, a micro-SD socket, or a GPS) and all the various minor components needed to make it work. The user simply then has to make a few connections (i.e., power, ground, and communication wires) between the microcontroller and breakout board to make it work. Breakout boards are important because a bunch of little things–for example, bypass capacitors and level shifters–have to be added for the principal components to work properly. These little things are often obvious to electrical engineers but can be overwhelming to beginners. Platforms like Arduino and Raspberry Pi might be the foundation of hobbyist electronics these days, but breakout boards make it possible to do cool things with those platforms.

One bit of advice to the DIY instrument designer: if you base your design on the Arduino, don’t use an actual Arduino in the final product. Use a bare-bones variant instead. Real Arduinos have a lot of nice features that unfortunately burn a lot of power, and you can reduce power draw by up to a factor of 30 by using a bare-bones knockoff. I used the Diavolino from EvilMadScientist at first, but am now designing my own board with a built-in efficient power supply instead.

jfa-gps        jfa-adc


Top left: GPS breakout board. Top right: analog-digital converter breakout board. Bottom: Arduino Uno, the most common Arduino version.

After getting the breakout boards to play nicely with the Arduino, it was time to design a printed circuit board (PCB) to house them. This might have been the most daunting part of this process. Two circuit design programs are common among hobbyists: KiCAD (free and open-source), and the light version of Eagle (free, not open-source, restricted to non-commerical use, but popular). Like a lot of scientific software, these programs take a while to learn.

In each program, the first step is to draw a schematic showing conceptually how components connect to each other. So, for example, if your circuit included a resistor and capacitor, your schematic would include the resistor symbol connected to a capacitor symbol, but no information about the size, shape, or position of the components.


Schematic editor in KiCAD

After drawing the schematic, the user decides how to lay out the circuit in physical space–specifically, where the components and electrical connections are located on the top and bottoms surfaces of the circuit board. The first step is choosing a physical footprint for each component. Then, a PCB editor window helps the user place component footprints on physical locations on the board and draw wires connecting them. The files created in this process can be sent to a manufacturer (I use Advanced Circuits, based in Aurora, Colorado, USA).


PCB Editor in KiCAD

The final product is called the Gem infrasound logger (named for the “Gem State” Idaho, where it was developed). Parts for it cost about $250 and it takes a few hours to assemble. This is about an order of magnitude cheaper than the cheapest commercial alternative. On the other hand, I put an uncountable number of hours (hundreds, at least) into designing and revising the Gem. On the other other hand, I learned some valuable skills in the process, and my next electronics project (a power-efficient Arduino board) was much easier as a result.

And of course, it’s turned out to be useful in applications beyond volcanoes. Danny Bowman (of Sandia National Labs, and this blog) has launched them on balloons. Tim Ronan (grad student at UNC-Chapel Hill) used them in his research studying river rapids. (Turns out that being lightweight is important when microphones have to be installed by kayak through class-IV whitewater!) Danny and Tim both helped me a lot by testing Gem versions that were still in development, for which I am grateful.

Was it worth it? As a grad student, my time is cheap and half my job is to learn new skills, so spending a lot of it learning how to do this was a good investment. If I was a professional scientist whose labor was more expensive, it might not be such a good decision: better to pay an engineer to do it, even if the product costs more to develop.

In any case, the final product justifies the effort, regardless of who did it. I now have a cheap logger that I can put high on volcanoes and on balloons. It’s been used in several projects around the world now, and it will remain a key part of my infrasound research.


A solar balloon carrying a Gem lifting off in Albuquerque, NM, USA. Photo by Danny Bowman.


A subset of the many sites where the Gem has been tested.

Accessing ensemble weather models with rNOMADS

Downloading a weather model and using it to predict stuff is all well and good – but what are the sources of error?  Specifically, how accurate is the atmospheric parametrization?   Luckily, NOMADS provides sets of models with slightly different initialization values.  The result is a set of realizations that captures the variability of the model product.  Here’s how to get that product, and examples of what you can do with it.


#Get the latest ensemble model run
model.urls <- GetDODSDates("gens")
latest.model <- tail(model.urls$url, 1)
model.runs <- GetDODSModelRuns(latest.model) <- tail(model.runs$[grepl("all",
    model.runs$], 1)

#Define region of interest: Chapel Hill, NC
lon <- -79.052104
lat <- 35.907553

#Set up DODS model grid indices
#Use GetDODSModelRunInfo() to figure out how to do this for other products
lons <- seq(0, 359, by = 1)
lats <- seq(-90, 90, by = 1)

lon.diff <- abs(lon + 360 - lons)
lat.diff <- abs(lat - lats)

model.lon.ind <- which(lon.diff == min(lon.diff)) - 1 <- which(lat.diff == min(lat.diff)) - 1

#Set up call to NOMADS GrADS-DODS server
#Analysis(?) model only
time <- c(0, 0)
#Longitude grid
node.lon  <- c(model.lon.ind - 2, model.lon.ind + 2)
#Latitude grid  <- c( - 2, + 2)
#Temperature, wind speeds, and geopotential height
variables <- c("tmpprs", "ugrdprs", "vgrdprs", "hgtprs")
levels    <- c(0, 25) #All available levels
ensemble <- c(0, 20)  #All available ensembles <- DODSGrab(latest.model,, variables,
    time, node.lon,, levels = levels, ensemble = ensemble)

#Plot temperature variability
plot(c(-65, 25), c(0, 35), xlab = "Temperature (C)",
    ylab = "Geopotential Height (km)", type = 'n')

for(k in ((ensemble[1]:ensemble[2] + 1))) { <- SubsetNOMADS(, ensemble = c(k),
        variables = c("hgtprs", "tmpprs"))
    profile <- BuildProfile(, lon, lat)
        which(profile[[1]]$variables == "tmpprs"), 1] - 272.15,
        which(profile[[1]]$variables == "hgtprs"), 1] / 1000)

#Plot winds
zonal.wind <- NULL
merid.wind <- NULL
height     <- NULL

for(k in ((ensemble[1]:ensemble[2] + 1))) { <- SubsetNOMADS(,
        ensemble = c(k), variables = c("hgtprs",
        "ugrdprs", "vgrdprs"))
    profile <- BuildProfile(, lon, lat)
    hgt     <- profile[[1]]$[,
        which(profile[[1]]$variables == "hgtprs"),]
    ugrd    <- profile[[1]]$[,
        which(profile[[1]]$variables == "ugrdprs"),]
    vgrd    <- profile[[1]]$[,
        which(profile[[1]]$variables == "vgrdprs"),]

   synth.hgt <- seq(min(hgt),
       max(hgt), length.out = 1000)
   ugrd.spline <- splinefun(hgt, ugrd, method = "natural")
   vgrd.spline <- splinefun(hgt, vgrd, method = "natural")
   zonal.wind[[k]] <- ugrd.spline(synth.hgt)
   merid.wind[[k]] <- vgrd.spline(synth.hgt)
   height[[k]] <- synth.hgt
PlotWindProfile(zonal.wind, merid.wind, height, lines = TRUE,
    points = FALSE, elev.circles = c(0, 15000, 30000),
    elev.labels = c(0, 15, 30), radial.lines = seq(45, 360, by = 45),
    colorbar = TRUE, invert = FALSE,
    point.cex = 2, pch = 19, lty = 1, lwd = 1,
    height.range = c(0, 30000), colorbar.label = "Wind Speed (m/s)")

Here’s atmospheric profiles from GFS ensemble runs on November 24, 2016 for Chapel Hill, NC. Temperature is quite variable at low altitudes (several degrees Celsius) and at 5 km above sea level (a couple degrees). Ensemble runs are more consistent for the rest of the atmosphere.


Temperature profile above the Geology Department at UNC Chapel Hill for November 24, 2016 at 18:00 UTC.

Wind speeds are pretty consistent, at least at the resolution of the color scale I’m using.  Wind direction varies by a few degrees below 15 km, but becomes quite a bit less reliable between 15 and 30 km altitude.  This is one reason that our solar balloon trajectories are so hard to predict.  The other reason is because we still don’t really understand the physics of solar balloon flight, but that’s a subject for another post.


How to build a high altitude solar balloon

This balloon can deliver a 2 lb payload to 72,000 ft (22 km) and fly for as long as the sun shines.  It can be hand launched by two people without the aid of electricity and lift gas.  The envelope is built from cheap, easy to find materials.  Total construction time is 4-6 hours for a team of two.

It’s best to find a large area, such as a gym, for building the envelope.  Take care to not damage the plastic – I recommend taking your shoes off so that you can step on the balloon material without ripping it.  When it comes time to darken the envelope, I highly recommend *not* doing it somewhere where lots of charcoal dust will cause a problem.  We recently did it in a parking deck, which meant that spills were no big deal and also kept the wind from blowing the balloon around.


-400 x 12 foot sheet of 0.33 mil plastic sheeting (sold as “light duty paint dropcloth” at hardware stores)

-Several rolls of heavy duty clear packing tape, such as these on Amazon.


-Permanent marker

-Tape measure

-Heavy duty string or cord (I use parachute cord)

-Air float charcoal, at least 1 lb

Building the envelope:

This is where you cut the plastic into the required shape, tape it together into a balloon, and check it for holes.  Click here to see a time lapse of this process.

Step 1: Cut the plastic sheeting into five 30 ft sections.  This is around the 10 second mark in the video above.

Step 2: Unfold them until you have five 30 x 12 rectangular sheets of plastic.  This is around the 15 second mark in the video above.

Step 3.  Fold each sheet once across the longer section and once across the shorter section.  Now you have five 15 x 6 ft sections.  This is between the 15 and 25 second mark in the video.

Step 4.  Lay the five sheets on top of each other, all facing the same way.  Find the corner that forms the center of the original sheet (this is where the fold seams all meet each other).  That corner is in the video around the 28 second mark, next to the guy in the blue shirt.  We spend

Step 5.  Consider the corner described in the previous point as the origin, the long part of the sheets as the X axis, and the short part of the sheets as the Y axis, draw the following points using a permanent marker (units in inches):


0 72

18 71

36 68

54 64

72 58

90 51

108 42

126 33

144 22

162 11

180 0

These points describe a half gore pattern, which is how we turn two dimensional objects (plastic sheets) into a 3 dimensional object (a spherical balloon).  Here, it happens to be a sine curve.  This is from the 40 to the 50 second mark in the time lapse.

Step 6:  Carefully insure that all sheets in the stack are lined up with each other (from about 28 to 40 seconds in the video).  Then, using a pair of scissors, carefully cut along the curved line defined by the points drawn on the top sheet (50-52 second mark).

Step 7: Unfold the sheets; you should have 5 diamond shaped ones.  These are gores, and they form the envelope of the balloon.  The other, roughly triangular pieces of plastic are trash (52-54 second mark).

Step 8:  Tape one edge of the first gore to one edge of the second gore using packing tape.  The seam should be centered in the tape, with no gaps between successive pieces of tape.  We have one person hold the two sheets together and the other tape them together, see photo below:


Taping the gores together.  If you have more people, you can have multiple teams going at once!  Photo by Mary Lide Parker, UNC Research Communications.

Step 9.  Add the next three gores successively, to make an ever larger sheet of plastic.  Finally, tape the two ends of the sheet together: you’ve now made a ball a little more than 19 feet across (the envelope of the balloon!)  This process takes up from the 1 minute to about the 2 minute mark in the video.

Step 10:  Find one of the two “poles” of the balloon (where the taped seams all meet).  Cut the pole off to make a hole about 5 feet across.  This will become the bottom of the balloon, and allow you to fill it with air.  We do this at 2:14 in the video.

Step 11:  Carefully tow the balloon back and forth, holding the hole open.  It will begin to fill with air.  This is from 2:15 to 2:17.


Filling the balloon with air prior to checking for holes.  Photo credit: Mary Lide Parker, UNC Research Communications.

Step 12:  At this point, it should be pretty clear whether or not you built the balloon correctly.  If everything looks good, send a brave soul inside to check the envelope for holes (gaps in seam tape are the most common culprits).  Someone on the outside can fix the holes as they are found.  Be careful, of course, since the air supply in there is finite.  This is from 2:18 to 2:36 in the video.


Checking each seam for holes.  Photo credit: Mary Lide Parker, UNC Research Communications.

Step 13:  Deflate and pack the balloon.  Start from the pole opposite the hole, and slowly push air towards the open end of the balloon.  Don’t go too fast or you’ll pop sections of the balloon.  It’s pretty simple to then stuff the balloon into a big garbage bag for storage.  This is from 2:37 to the end of the video.

Rigging the balloon:

The open hole on one side of the balloon is very weak and susceptible to tearing.  Also, it does not provide any means of attaching a payload.  Thus, we need to reinforce it and provide a way to attach our equipment.

A simple way to do this is to run some tape around the bottom, poke some holes in the tape, attach some string, and tie your payload on.  Our first versions had this system, but it was not ideal; in fact it is probably why we had an “unscheduled rapid disassembly” at 72,000 ft last May.

A much better way is to tie a length of strong cord (parachute cord, for example) into a loop slightly larger than the opening of the balloon.  Pull the opening through the loop, fold it around the loop, and tape the edge of the opening to the outer envelope of the balloon.  This provides a very strong lining system for the bottom.  A payload can be attached by tying guy lines onto the cord loop.  I believe the best place for these guy lines is right at each seam, since the seam tape provides a means of distributing the load along a relatively strong portion of the envelope.  The photo below shows one edge of the balloon with the parachute cord folded in, as well as one payload attachment string.


Darkening the envelope:

This is the most fun part (besides launching).  Find a place that is protected from the wind but will allow you to make a big mess.  As mentioned earlier in the post, an indoor parking deck is ideal.

Unpack the balloon and lay it out on the ground. Throw a generous quantity of air float charcoal into the open end, and shake it all the way through the balloon.  The charcoal is so fine it will coat the interior of the balloon, changing it from white to dirty gray.


Midway through darkening our solar balloon.

Then, wait for good weather conditions:


Two solar balloons and their payloads in storage.


The launch procedure is simple: tow the balloon back and forth until it fills with air, attach the payload, let the whole thing heat up for a bit, and off it goes.   Here’s a video of us doing it.  Simple, right?  No.

Actually, launching solar balloons is hard.  It’s a lot harder than helium balloons, since ground conditions are much more restrictive.  With this in mind:

An ideal day for solar ballooning has clear skies and calm ground winds.  This is actually pretty rare, and you may have to wait several weeks for an opening.  If you start to get impatient, keep in mind that even winds barely strong enough to move leaves can make handling a 20 foot tall balloon very dicey.  Early mornings (just after dawn) are best.

An ideal site for a launch is a large open field, where slowly rising balloons will not get caught in trees, power lines, etc.  An alternative is a parking lot between tall buildings, since wind tends to go around them.  This is risky, though, since the balloon can still hit and potentially snag on them.

Finally, if you are planning on recovering your payload, realize that the balloon will fly until the sun sets.  This means that even a 10 mph wind can carry the balloon 120 miles, assuming 12 hours at float.  Many times, the winds in the upper troposphere/lower stratosphere are much stronger.  Careful consideration of the wind profile from 0 to 100,000 ft above sea level is thus imperative before attempting a full day flight with payload recovery.

Happy ballooning!

Predicting the Flight Path of a Solar Balloon

Balloons that fly on solar power – what could be better?  Unfortunately, the physics of these balloons is complex and reliable data on how they fly is hard to come by. On this blog, we’ve discussed our attempt to come up with a numerical model of solar balloon flight as well as the data set from our solar balloon that made it to 22 km (72,000 ft) last May.  In this post, we present an empirically-derived solar balloon flight model based on data we collected on the high altitude flight mentioned above.

First off: a disclaimer.  This model is generated from data collected by one flight of a specific design of solar balloon.  While we hope that it captures some general features of a solar balloon flight, we can’t be sure.  Furthermore, different balloon designs and atmospheric conditions will cause inevitable (and at this point, unpredictable) deviations from the model we describe.  Take it with a big grain of salt.

Ascent Rate

We smoothed the GPS altitude data from our high altitude launch and performed a 1st order Tikhonov regularization to derive an ascent rate versus altitude model for our solar balloon.  The plot is below, if you want the numbers click here.

Modeled ascent rate versus actual ascent rate for our high altitude solar balloon.

Modelled ascent rate versus actual ascent rate for our high altitude solar balloon.

The solar balloon initially ascends at about 1.5 meters per second, reaches a maximum of about 2.5 meters per second at around 15 km elevation (just below the tropopause), and rapidly decreases as the balloon approaches neutral buoyancy at 22 km elevation.  This is fortuitous, since the strongest winds in this elevation profile typically exist in the region where the balloon is ascending the fastest.  In contrast, the lower stratosphere (18-22 km) is usually calmer.  The exciting possibility in this trajectory data is that we may be able to park future balloons in this low wind “sweet spot”, and thus recover payloads relatively close to the launch site.

The modelled ascent rate lacks the vertical velocity oscillations in the real data; this is by design.  We suspect those oscillations are either due to gravity waves in the atmosphere or uneven heating of the balloon envelope.  In any case, we would not expect to see the exact same ones on future flights.   Furthermore, removing the oscillations has little effect on the accuracy of the ascent rate model, as the plot below shows.

Modeled elevation vs actual elevation for the May 29, 2015 high altitude solar balloon flight.

Modeled elevation vs actual elevation for the May 29, 2015 high altitude solar balloon flight.

However, a comparison between the actual ground track of the balloon versus one using horizontal winds calculated from archived weather forecast data shows a considerable deviation:

Modelled versus actual ground path of the high altitude solar balloon.

Modelled versus actual ground path of the high altitude solar balloon.

This may be because of the poor spatial resolution of the archived Global Forecast System model we used (1 x 1 degree) as well as the lack of a precise match between the prediction time and the flight time.  Although the two trajectories are rotated, their general form is similar.  While the forecast skill is not ideal, it still gives a reasonable approximation of what we could have expected on launch day.  To this end, we are utilizing the simple vertical velocity model derived above in combination with predicted wind speeds to generate potential flight paths.  Here’s an example from September 28, 2015:

Example of a modelled solar balloon flight path. The green diamond is the launch site, the red line is the ascent, the dashed line is 8 hours of drifting at neutral buoyancy, and the blue circle is the predicted balloon location around sunset.

Example of a modelled solar balloon flight path. The green diamond is the launch site, the red line is the ascent, the dashed line is 8 hours of drifting at neutral buoyancy, and the blue circle is the predicted balloon location around sunset.

It may not be perfect, but it sure beats what we used to use.

Stratospheric Solar Balloon Flight

It took three years and several false starts, but we finally got a solar balloon with a video camera on board to take off successfully.  Not only that, but the balloon reached an elevation of over 22,000 meters (72,000 feet), well into the stratosphere!  Then, it suffered what Elon Musk calls a “rapid unscheduled disassembly,” sending the payload into a 22 kilometre free fall that ended in the muddy banks of a cow pond.  Despite this, the photos, video, and GPS track were all recovered.  Here’s the flight video:

The balloon envelope consisted of a 19 foot diameter sphere of 0.31 mil clear plastic paint drop cloth.  Since the drop cloth comes in 12 x 400 foot sheets, we constructed the envelope from 5 gores that were 12 feet wide at the equator.  We attached the gores together using clear shipping tape and darkened the interior of the balloon with black paint pigment.  Each gore seam had a string attached to the bottom with black duct tape.  The opening at the bottom of the balloon is about 6 feet across, allowing two people to inflate it by hand (check out the full inflation and launch video).

The solar balloon in flight just after launch.  Image credit: Mary Lide Parker

The solar balloon in flight just after launch. Image credit: Mary Lide Parker

The payload consisted of a SPOT satellite tracker for recovery, an Arduino Uno with Adafruit High Altitude GPS Shield for trajectory determination, and a Raspberry Pi with camera module for video and stills.  The system was powered using a lithium battery pack meant for recharging cell phones (10 ampere hours).  All this was contained in a Tupperware box with a small hole to admit the camera lens.  We attached it to the balloon using four strings taped onto the box with white duct tape.  The four strings led to a fishing swivel to keep the payload from spinning too much.  We clipped it to the strings on the envelope using a black carabiner. Total payload weight was 800 grams (1.75 lbs).


Payload with the lid off, showing flight instrumentation (left) and payload just before launch (right).

We kept an eye on the wind profiles for about 5 months, since most of the time winds in the troposphere blow out to sea.  Finally, we waterproofed the payload and decided to risk a flight even if some winds were going east.  On May 29, the winds in the troposphere were pretty low (max 10 m/s or so) and with varying azimuth.  The stratosphere had a steady breeze going west, so we figured if we made it that high, we’d head back over land.  However, we had a much faster ascent rate and reached a much higher altitude than we anticipated, so we ended up not flying very far from the launch site.  You can download the trajectory data in text format here or Google Earth KML here.


Ground flight path (left), launch site is the origin. Altitude versus time (centre), local time was GMT – 4. Ascent rate versus time (right), local time was GMT – 4. I obtained the ascent rate by calculating a 1 minute moving average and dividing elevation by time.

The photos and video were very good quality considering that we were using the Raspberry Pi camera module (not the world’s most advanced camera).  The troposphere was pretty misty, and it seems like we even passed through a haze layer on the way up.  However, it could be that the lens fogged up temporarily.  Once we entered the stratosphere, the pictures are much better:


The view from 22 kilometres in the sky.

You can watch a slide show of all the photos here, and all the video clips stitched together here.

Just as we approached neutral buoyancy, the payload unexpectedly separated from the envelope and fell back down to Earth.  We kept GPS tracking until about 18 kilometres elevation, and as far as I can tell the box was falling at about 320 km/hr (200 mph).  The Arduino kept track of time even after losing GPS fix, continuing to record until the moment of impact.  Thus, we know that the payload fell the remaining 18 km in about 12 minutes.  The impact speed was probably less than 100 km/hr (60 mph).  The Tupperware payload box was cracked, and everything except the SPOT tracker stopped working.  Had we landed 10 centimetres or so west, we would have splashed down in a pond.  Luckily, we hit the mud on the pond’s edge (and missed the cows that were in the area).


The payload box at the impact site in Snow Camp, North Carolina.

We consider this flight mostly successful.  Our main objectives were to launch, recover, and extract data from an instrument package lifted with a solar balloon.  Furthermore, we wanted to inflate the solar balloon by hand.  Both of these objectives were reached. Our secondary goals were to fly until sunset, not land in the ocean, and make it to the stratosphere.  The flight was only about 2.5 hours, so we did not fly all day as we hoped.  However, we made it well into the stratosphere and were never in danger of ending up in the ocean.

We had a slightly tense launch when the payload got snagged on the eaves of a nearby building, but the balloon built up enough lift to detach itself in about 20 seconds.  The SPOT tracker did not record any positions during flight, so we did not know where the balloon was and were not even sure if the tracker was working.  In fact, it did not record positions until about an hour and a half after impact. The unexpected flight termination was upsetting as we did not anticipate having the payload detach from the envelope.  We assumed that either the envelope would rupture due to sun-induced heating at altitude or that it would deflate at sunset.  In either case, the payload would have had a large plastic streamer to slow it down to safe velocities.  Instead, it appears that the black duct tape we used to attach the payload strings to the envelope got too hot in the intense sunlight at 22 km.  This caused the payload to come loose from the balloon.  The lesson we learned from this is to never use dark coloured tape if there’s a chance the flight system will make it to extreme elevations.

How to install rNOMADS with GRIB file support on Windows

Two years ago, I wrote a software package for R called “rNOMADS” that interfaces with online weather and sea ice model repositories to gather data in real time, for free.  The data are delivered in two ways: a simple, pure R, cross platform interface using GrADS-DODS, and binary files in GRIB format.  The one issue with GRIB is that this format can’t be read directly into R; it requires the external program “wgrib2.”  Installing rNOMADS with GRIB support for Linux is covered in this post (Mac OS is probably similar).  I thought GRIB support for Windows was impossible until the guy who runs this blog casually told me he’d figured it out.  So, I finally got around to trying it myself, and I’m happy to say I got it to work!  Here’s how:

Step 1:

Download the most recent wgrib2.exe version and all DLL files from Wesley Ebisuzaki’s web site:  Click here.

Step 2:

Make a directory somewhere on your computer.   I chose:  C:\Program Files\wgrib2

Copy the .exe and the .dll files to this directory.

Step 3:

Append the directory path to the Windows PATH variable.  Find out how to do this here.

Edit: a user points out that sometimes this doesn’t work.  If not, change the path variable in R using Sys.setenv():

Sys.setenv("PATH" = "C:/Program Files/wgrib2")


Step 4:  If R is open, close and reopen it.  Then try the following command in the R interpreter:

If you get a bunch of text that looks like the image below, you’ve succeeded.  You can start reading GRIB files with rNOMADS!

Output of wgrib2 call from R.

Output of wgrib2 call from R.