40 Years Ago - The Wreck of the Edmund Fitzgerald

SS Edmund Fitzgerald (Image Wikipedia)

SS Edmund Fitzgerald (Image Wikipedia)

While I normally post technical bits or project reports, occasionally we examine a historical event that happened "on this day" and see what is known about it. Today marks 40 years since the sinking of the freighter the SS Edmund Fitzgerald. The ship disappeared November 10, 1975 with no distress call in the middle of a severe storm on the great lakes. The prescribed route took her from Superior, Wisconsin, across lake Superior, and towards Detroit with a load of ore pellets.  In this post I'll quickly give a synopsis of the storm and conditions of the sinking. A lot of research, videos, articles, and more have bene done on this event, so rather than re-write it all, we'll give a sense of the general circumstances and conjecture some on the theories of what happened.

After leaving port, the Fitz was joined by another freighter, the Arthur M. Anderson, that looks nearly identical. The ships were not far apart for much of their journey and were within about 10 miles of each other at the time of last contact. While 10 miles is rather close, it was a huge distance in the storm that was coming upon them. It was a classic winter gale that had been expected to track further south. Winds rose, snow blinded the pilots, and the waves continuously grew from a few feet to rouge wave events of about 35 feet. Storms like this have frequently claimed ships on the lake, with the Whitefish Point area (where the Fitz sank) containing over 240 ships. The lake alone has over 7,000 wrecks and 30,000 lives claimed.

Winds and/or equipment problems rendered the radar on the Fitz inoperable about 4:10 PM. Captain McSorley slowed down to close the range with the Anderson to get radar guidance. Later in the evening, the captain reported that the waves were high enough that the ship was taking significant seas on deck. The ship had also developed a bad list (i.e. was leaning to one side). At 7:10 PM the Anderson called McSorley to ask how the ship was faring, he said "We are holding our own." Minutes later the Fitz disappeared from the Anderson's radar screen and was gone without a single distress signal. All 29 on board perished and none were recovered. This probably wound't be anything but "another shipwreck" to the general public if it hadn't been for the Canadian songwriter Gordon Lightfoot. After reading about the accident, he wrote a ballad that described what it might have been like to be on the boat. The song (below) hit number 2 on the charts in 1976 and immortalized the Fitz and her crew.

The wreck was found shortly after the accident by using an aircraft mounted magnetometer. The finding was confirmed with a side-scan sonar and then with a robot submersible. The ship had a broken back, lying to two pieces on the lake bottom, about 530 feet down. The aft of the ship was upside down and about 170' from the forward section. The forward part of the wreck sits roughly upright.

Wreck Map (Image: Wikipedia)

Wreck Map (Image: Wikipedia)

There are several theories about how the Fitz sank, but none can be confirmed. The obvious theory is that the waves were too much for the boat, but there are likely more complicating factors. A set of rogue waves about 35 feet in height had struck the Anderson and were headed in the direction of the Fitzgerald. It is possible that these waves, which had just buried the aft cabins of the Anderson, were too much for the listing Fitzgerald and that it was submerged to never resurface. Another popular theory was that the cargo hold had flooded. The coast guard favors this theory as evidence at the site suggests that not all of the hold hatch clamps were fastened. The holds gradually flooded until the ship could no longer recover from a wave strike. While this helps explain the list, it doesn't fit with the long safety record of the hatch closures used on the boat. The NTSB favored a theory that the hatch covers collapsed under a very large and heavy boarding sea, the holds instantly filled, and the boat sank. That would explain the sudden disappearance - I'd think that if a slow flood was occurring, an experienced captain (which McSorley was) would have sent a distress signal. Some have even proposed that loose debris in the water or from the ship itself caused significant damage to the topside. Yet another theory was that the ship had raked a reef earlier in the day since it's navigational aides were out. The puncture slowly let water in and eventually it was too much to stay afloat. This theory has been mostly ruled out by the lack of evidence on the exposed keel of the ship and by no marks on the reef (surveyed shortly after the wreck). The final theory is simple structural failure. The hull was a new design that was welded instead of riveted. Former crew members and boat keepers said that the ship was very "bendy" in heavy seas and that paint would even crack due to the large strains.

This mechanical failure theory seems most likely to me. Repeated flexing and/or riding up on a set of large waves allowed the hull to fail and immediately plunge to the bottom. The hull was under excess strain due to water loading from topside damage. That water loading is what caused the list. While some say the proximity of the sections mean that it sank whole, I disagree. The ship was 729 feet long and sank in 503 feet of water! If it had plunged bow first, hit the bottom, then broke there should be more evidence on the bow that just isn't there. Think ships don't bend in heavy seas? Have a look at the video below of a cargo ship passageway. Note about 11 seconds in when the ship hits a 7-8 meter wave. That's much smaller that the rouge wave that may have hit the Fitz.

If you'd like to know more about the accident and see some interviews with experts, have a look at the Discovery channel documentary below. We will probably never know exactly how the Fitzgerald sank, but it's a very interesting and cautionary tale. It also reminds us of the incredible power of water and wind against practically anything that we can manufacture.

Setting up a Lab Thermal Chamber


I've been working on developing some geophysical instruments that will need some significant temperature compensation. Often times when you buy a sensor there is some temperature dependance (if not humidity, pressure, and a slew of other variables). The manufacturer will generally quote a compensation figure. Say we are measuring voltage with an analog-to-digital converter (ADC); the temperature dependance may be quoted as some number of volts per degree of temperature change over a certain range of voltages and temperatures. Generally this is a linear correction. Most of the time that is good enough, but for scientific applications we sometimes need to squeeze out every error we can and compare instruments. Maybe one sensor is sightly more temperature dependent than another; comparing the sensors could then lead us to some false conclusions. This means that sometimes we need to calibrate every sensor we are going to use. In the lab I work in, we calibrate all of our transducers every 6 months by using transfer standards. (Standards, transfer of standards, and calibration theory are a whole series of posts in themselves.)

To do thermal calibrations it is common to put the instruments into a thermal chamber in which we can vary the temperature over a wide range of conditions while keeping the physical variable we are measuring (voltage, pressure, load, etc) constant. Then we know any change in the reading is due to thermal effects on the system. If we are measuring something like tilt or displacement, we have to be sure that we are calibrating the electronics, not signals from thermal expansion of metals and materials that make up our testing jig.

I scoured EBay and the surplus store at our University, but only found very large and expensive units. I remembered that several years ago Dave Jones over at the EEVBlog had mentioned a cheap alternative made from a peltier device wine cooler. I dug up his video (below) and went to the web again in search of the device.

I found the chamber marketed as a reptile egg incubator on Amazon. The reviews were not great, some saying the unit was off by several degrees or did not maintain the +/- 1 degree temperature as marketed. I decided to give it a shot since it was the only affordable alternative and if it didn't work, maybe I could hack it with a new control system and use the box/peltier element with my own system. In this post I'm going to show you the stock performance of the chamber and some initial tests to figure out if it will do the job.

As soon as it arrived I setup the unit and put an environmental sensor in (my WxBackpack for the Light Blue Bean used back in the drone post) inside. I wanted to see if it was even close to the temperature displayed on the front and how good the control was with no thermal load inside. There was a small data drop-out causing a kink early in the record (around 30 C). It looks like the temperature is right on what I had set it to with the quoted +/- 1 degree range. There is some stabilization time and the mean isn't the same as the set point, but that makes sense to me, you don't want to overheat eggs! This looks encouraging overall. I also noticed that the LED light inside the chamber flickered wildly when the peltier device was drawing a lot of power heating/cooling the system. I then opened the door and set the unit to cool. After reaching room temperature, I closed the door and went to bed. It certainly isn't fast, but I was able to get down to about 2C with no thermal load. That was good enough for me. Time to add a cable port, checkout the LED issue, and test with some water jars for more thermal mass.

Initial test of the thermal chamber with nothing inside except a temperature logger. Set point shown by dashed line.

Initial test of the thermal chamber with nothing inside except a temperature logger. Set point shown by dashed line.

The next step was to add a cable port to be able to get test cables in and out. I decided to follow what Dave did and add a 1.5" test port with a PVC fitting, a hole saw, and some silicone sealant. Below are a few pictures of drilling and inserting the fitting. I used Home Depot parts (listing below). I didn't have the correct size hole-saw. That's happened a lot lately, so I invested in the Milwaukee interchangeable system. I got a threaded fitting so I can put a plug in if needed. the time honored tradition is to put your cables through the port and stuff a rag in though. This works as well as a plug generally, but it's nice to have the option.

Screenshot 2015-10-31 14.44.16

Before, during, and after cable port placement. The center of the hole is 7 3/8" back from the front do

Before, during, and after cable port placement. The center of the hole is 7 3/8" back from the front door seal, and 5 1/8" up from table top level. I used gel super glue to quickly fix the fitting to the plastic layers and foam. After that dried, I used silicone bath adhesive/sealant to seal the inside and outside. The edge of a junk-mail credit card offer made smoothing the silicone easier.

While working inside the chamber I pulled out the LED board and noticed a dodgy looking solder joint. I reflowed it. I also pulled the back off the unit to make sure there were no dangerous connections or anything that looked poor quality. Nothing jumped out.

I put the whole thing back together and put a sensor in to monitor the environment and tested again. This time I tried a few different set points with and without containers of water inside the chamber. First with nothing but the sensor setup inside:


For both heating and cooling the performance under no thermal load (other than the sensor electronics) was pretty good. Cooling is rather slow and more poorly controlled than heating though.

Next I put sealed containers of water on the shelves of the chamber to add some thermal mass and see if that changed the characteristics of the chamber any. It did slow the temperature change as expected, but appears to have had little other effect (I didn't wait long enough for stabilization on some settings).


With a water load the chamber had similar performance, but was slower in getting to temperature as expected.

It looks like at temperatures above ambient the chamber has a stability of +/- 1 degree. Below ambient it becomes a couple of degrees. The absolute reading drifts a bit too. Setting the chamber to a given reading always resulted in stabilization within about a degree of the setting though.

I think this will be a nice addition to my home lab. While the unit isn't incredibly accurate, I will be recording the device temperature anyway, so that works for me. It'd be nice to cool down more quickly though, so I may facilitate that with some dry ice. Stay tuned as I'll be testing instruments in there sometime in the next month or so.

P.S. - The LED light still flickers in a way that indicates unstable power/connection. Not a deal breaker for me since I don't really need the light, but something to remember.

Debugging - Book Review


I end up doing a lot of debugging, in fact every single day I'm debugging something. Some days it is software and scripts that I'm using for my PhD research, some days it is failed laboratory equipment, and some days it's working the problems out of a new instrument design. Growing up working on mechanical things really helped me develop a knack for isolating problems, but this is not knowledge that everyone has the occasion to develop. I'm always looking for ways to help people learn good debugging techniques. There's nothing like discovering, tracking down, and fixing a bug in something. Also, the more good debuggers there are in the world, the fewer hours are waisted fruitlessly guessing at problems.

I'd heard about a debugging book that was supposed to be good for any level of debugger, from engineer to manager to homeowner. I was a little suspicious since the is such a wide audience, but I found that my library had the book and checked it out; it is "Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems" by David Agans. The book sat on my shelf for a few months while I was "too busy" to read it. Finally, I decided to tackle a chapter a day. The chapters are short and I can handle two weeks of following the book. Each morning when I got to work, I read the chapter for that day. One weekend I read an extra chapter or two because they were enjoyable.

I'm not going to ruin the book, but I am going to tell you the 9 rules (it's okay, they are also available in poster form on the book website).

  1. Understand the System
  2. Make It Fail
  3. Quit Thinking and Look
  4. Divide and Conquer
  5. Change One Thing at a Time
  6. Keep an Audit Trail
  7. Check the Plug
  8. Get a Fresh View
  9. If You Didn't Fix It, It Ain't Fixed

They seem simple, but think of the times you've tried to fix something and skipped around because you thought you knew better to have it come back to sting you. If you've done a lot of debugging, you can already see the value of this book.

The book contains a lot of "war stories" that tell tales of when a rule or several rules were the key in a debugging problem. My personal favorite was the story about a video conferencing system that seemed to randomly crash. Turns out the compression of the video had problems with certain patterns and when the author wore a plaid shirt to work and would test the system, it failed. He ended up sending photocopies of his shirt to the manufacturer of the chip. Fun stories like that made the book fun to read and show how you have to pay attention to everything when debugging.

The book has a slight hardware leaning, but has examples of software, hardware, and home appliances. I think that all experimentalists or engineers should read this early on in their education. It'll save hours of time and make you seem like a bug whisperer. Managers can learn from this too and see the need to provide proper time, tools, and support to engineering.

If you like the blog, you'll probably like this book or know someone that needs it for Christmas. I am not being paid to write this, I don't know the author or publisher, but wanted to share this find with the blog audience. Enjoy and leave any comments about resources or your own debugging issues!

Using Visual Mics in Geoscience

Image: TED Talk

Image: TED Talk

Last time I wrote up the basics of a tip sent in by Evan over at Agile Geoscience. This technology is very neat, if you haven't read that post first, please do and watch the TED talk. This post is going to be about how we could apply this to problems in geoscience. Some of these ideas are "low hanging fruit" that could be relatively easy to accomplish, others are in need of a few more PhD students to flesh them out. I'd love to work on it myself, but I keep hearing about this thing called graduation and think it sounds like a grand time. Maybe after graduation I can play with some of these in detail, maybe before I can just experiment around a bit.

In his email to me, Evan pointed out that this visual microphone work IS seismology of sorts. In seismology we look at the motion of the Earth with seismometers or geophones. If we have a lot of them and can look at the motion of the Earth in a lot of places over time, we can learn a lot about what it's like inside the Earth. This type of survey has been used to understand problems as big as the structure of the Earth and as small as finding artifacts or oil in shallow deposits. In (very) general terms we look at very low frequency waves for Earth structure problems with periods of a second to a few hundred seconds. For more near surface problems we may look at signals up to a few hundred cycles per second (Hz). Remember in the last post I said that we collect audio data at around 44,200 Hz? That's because as humans we are able to hear up to around 20,000 Hz. All of this is a lot higher frequency than we ever use in geoscience... I'm thinking that makes this technique somewhat easier to apply and maybe even able to use poor quality images.

So what could it be used for? Below are a few bullet points  of ideas. Please add to them in the comments or tear them apart. I agree with Evan that there is some great potential here.

  • Find/visualize/simulate stress and strain concentration in heterogeneous materials.
  • Extract modulus of rock from video of compression tests. Could be as simple as stepping on the rock.
  • Extend the model to add predicted failure and show expected strain right before failure.
  • Look at a sample from multiple camera views and combine for the full anisotropic properties. This smells of some modification of structure from motion techniques.
  • Characterize complicated machines stiffness/strain to correct for it when reducing experimental data without complex models for the machine.
  • Try prediction of building response during shaking.
  • What about perturbing bodies of water and modeling the wave-field?

With everything in science, engineering, and life, there are tradeoffs. What are the catches here? Well, the resolution is pretty good, but may not be good enough for the small differences in properties we sometimes deal with. In translating this over to work on seismic data I think a lot of algorithm changes would have to happen that may end up making it about the same utility as our first-principles approaches. A big limitation for earthquake science is what happens at large strains. The model looks at small strains/vibrations to model linear elastic behavior. That's like stretching a spring and letting it spring back (remember Hooke's Law?). Things get interesting in the non-linear part of deformation when we permanently deform things. Imagine that you stretch the spring above much further than it was designed to be. The nice linear-elastic behavior would go away and plastic deformation would start. You'd deform the spring and it wouldn't ever spring back the same way it was again. Eventually, as you keep stretching, the spring would break. The non-linear parts of deformation are really important to us in earthquake science for obvious reasons. For active seismic survey people, the small strain approximation isn't bad though.

Another issue I can imagine is combining video from different orientations to recover the full behavior of the material. I don't know all of the details of Abe's algorithm, but I think it would have problems with anisotropic materials. Those are materials that behave differently in different directions. Imagine a cube that can be easily squeezed on two opposing faces, but not easily squeezed on the others. Some rocks behave in such a way (layered rocks in particular). That's really important since they are also common rocks for hydrocarbon operations to target! Surrounding the sample area with different views (video or seismic) and using all of that information should do the job, but it's bound to be pretty tricky.

The last thing that strikes me is processing time. I don't think I've seen any quotes of how long the processing of the video clips took to recover the audio. While I don't think it's ludicrous, I think the short clips could conceivably take a few hours per every 10 seconds (this is a guess). For large or long duration geo experiments that could become an issue.

So what's the end story? Well, I think this is a technology that we haven't seen the last of. The techniques are only going to get better and processors faster to let us do more number crunching. I'm curious to watch this develop and try to apply it in some basic experiments and see what happens. What would you try this technique on? Leave it in the comments!

Listening to Sound with a Bag of Chips


Today I wanted to share some thoughts on some great new technology that is being actively developed and uses cameras to extract sound and physical property information from everyday objects. I had heard of the visual microphone work that Abe Davis and his cohorts at MIT were working with, but they've gone a step further recently. Before we jump in, I wanted to thank Evan Bianco of Agile Geoscience for pointing me in this direction and asking about what implications this could have for rock mechanics. If you like the things I post, be sure to checkout Agile's blog!

Abe's initial work on the "visual microphone" consisted of using high speed cameras and trying to recover sound in a room by videoing an object like a plant or bag of chips and analyzing the tiny movements of the object. Remember sound is a propagating pressure wave and makes things vibrate, just not necessarily that much. I remember thinking "wow, that's really neat, but I don't have a high speed camera and can't afford one". Then Abe figured out a way to do this with normal cameras by utilizing the fact that most digital cameras have a rolling shutter.

Most video cameras around shoot video at 24 or 32 frames (still photos) each second (frames per second or fps). Modern motion pictures are produced at 24 fps. If we change the photos very slowly and we just see flashing pictures, but around the 16 fps mark our mind begins to merge the images into a movie. This is an effect of persistence of vision and it's a fascinating rabbit hole to crawl down. (For example, did you know that old time film projectors flashed the same frame more than once? The rapid flashing helped us not see flickers, but still let the film run at a slower speed. Checkout the engineer guy's video about this.) In the old days of film, the images were exposed all at once. Every point of light in the scene simultaneously flooded through the camera and exposed the film. That's not how digital cameras work at all. Most digital cameras use a rolling shutter. This means the image acquisition system scans across the CCD sensor row by row (much like your TV scans to show an image, called raster scanning) and records the light hitting that sensor. This means for things moving really fast, we get some strange recordings! The camera isn't designed to capture things that move significantly in a single frame. This is a type of non-traditional signal aliasing. Regular aliasing is why wagon wheels in westerns sometimes look like they are spinning backwards. Have a look at the short clip below that shows an aircraft propeller spinning. If that's real I want off the plane!

But how does a rolling shutter help here? Well 24 fps just isn't fast enough to recover audio. A lot of audio recordings sample the air pressure at the microphone about 44,200 times per second. Abe uses the fact that the scanning of the sensor gives him more temporal resolution than that rate at which entire frames are being captured. The details of the algorithm can get complex, but the idea is to watch an object vibrate and by measuring the vibration estimate the sound pressure and back-out the sound.

Sure we've all seen spies reflect a laser off glass in a building to listen to conversations in the room, but this is using objects in the room and simple video! Early days of the technology required ideal lighting and loud sounds. Here's Abe screaming the words to "Mary had a little lamb" at a bag of potato chips for a test.... not exactly the world of James Bond.

Screenshot 2015-09-12 13.19.56


As the team improved the algorithm, they filmed the bag in a natural setting through a glass pane and recovered music. Finally they were able to recover music from a pair of earbuds laying on a table. The audio quality isn't perfect, but good enough that Shazam recognized the song!

The tricks that the group has been up to lately though are what is the most fascinating. By videoing objects that are being minority perturbed by external forces, they are able to model the object's physical properties and predict its behavior. Be sure to watch the TED talk below to see it in action. If you're short on time skip into about the 12 minute mark, but really just watch it all.

By extracting the modulus/stiffness of objects and how they respond to forces, the models they create are pretty lifelike simulations of what would happen if you exerted a force on the real thing. The movements don't have to be big. Just tapping the table with a wire figure on it or videoing trees in a gentle breeze is all it needs. This technology could let us create stunning effects in movies and maybe even be implemented in the lab.

I've got some ideas on some low hanging fruit that could be tried and some more advanced ideas as well. I'm going to talk about that next time (sorry Evan)! I want to make sure we all have time to watch the TED video and that I can expand my list a little more. I'm thinking along the lines of laboratory sensing technology and civil engineering modeling on the cheap... What ideas do you have? Expect another post in the very near future!

PSA About ABS - Follow Up

Just a very short follow up about my previous ABS post. I was able to paint the part with a brush and some IKEA BEHANDLA Glazing paint. This is the paint I used on my pine night-stands in 2012, so it is a little old, but it did the trick. The smooth surface on the bottom of the stand didn't hold paint very well, but that's okay. The textured sides where the printer slowly built up the part gave lots of surface area to color and it looks like it belongs. Happy accident, but worth remembering if you want a fake wood texture. You could even expose different parts of the roll of plastic intentionally for a very interesting color pattern, but go easy or you may hurt the plastic's integrity.

2015-08-30 21.35.10 2015-08-30 21.35.30

While researching about ABS damage from UV exposure, I found out that there are now UV sensitive plastic filaments available. The world of 3D printing moves very fast and I was apparently not up to speed on some of the new materials that are out there. Below is a video of the filament being exposed (not me or my filament obviously).

PSA About ABS - A Surprising Tale in 3D Printing

A little over a year ago I got a 3D printer. I've had a great experience with it! I had printed a lot of lab hardware and some fun things, but then let it sit around for a few months while things were very busy in other parts of work. This past week was maker week in State College, so there were lots of 3D printing demonstrations around town and other maker projects. I decided I should get things fired up again. I've got a couple of new projects that will need custom enclosures built. Without being able to have a spot-welder in my apartment, I'm pretty much limited to plastics or paying for the manufacturing.

I re-leveled and calibrated the bed and z-axis mechanism. I carefully re-checked the extruder calibration to be sure that I got the appropriate amount of plastic extruded. Everything looked great, so I downloaded a simple, but utilitarian part for my Apple Watch off thingiverse. Using Slic3r, I created the GCode and sent it off to print. Everything started off like normal, so I left the printer running to deal with other tasks. I came back later and too many surprise the part had stripes!

2015-08-29 19.52.56

I've always printed with ABS plastic. It's not that I don't want to use PLA, it's just what I've always had on hand and what I know how to work with. I happened to have left the white roll of plastic on the printer after my last print. Since my printer sits next to the window, it gets some sunlight, especially in the morning hours. Not the best location, but it's the only location I can place it for the moment. It looks like the UV radiation has damaged my filament! Every time the part of the roll that was exposed heavily comes around, I get a band. For a simple charging stand, I'm not too upset. I could even try some of the ABS bleaching brews used by antique computer collectors. I may just paint the whole thing with paint that matches my wooden night stand. Maybe this will give me a false wood grain look?

I wanted to confirm that the stripes corresponded to a revolution of the spool. The whole part is darker than parts printed from the same roll months ago, but I'd guess the darker bits were on the top of the roll. By analyzing the GCode that produced the part, I calculated that the printed used about 5.1 meters of filament (<$2). The roll has been used down to a coiling diameter of about 150 mm. That means I expect about 10-11 turns of the reel for the print. I see 7-10 layers depending on what I count, so I'll call that close enough.

2015-08-29 20.34.26

Well that's the story for now. Don't leave your ABS in the sunlight, even on your machine. I've been meaning to get a dust cover for the machine and this is even more reason to do so and make sure it's opaque.

Drone Sounding Prototype

Again we have a short project post in-between the posts of the open science series (part 3 coming soon)! This time I want to share a fun little project involving cheap drones and an instrument pack that I designed on top of the Light Blue Bean module. The pack uses an HTU21D temperature/humidity sensor and a BME180 pressure sensor. I designed the board in the open-source PCB/EDA tool KiCAD. Should you want to reproduce the boards, the files to send off to a board house are available on a GitHub repository here.

I designed the pack to be a measurement device for a home, truck, or airplane of the weather enthusiast or storm chaser. Ideally it will send the data to a smartphone/tablet that then sends it out to the web or lets you do whatever you want with it. It was also a good excuse to play with the bean after hearing about it. While delivering another product to a friend, we decided to strap this sensor to a small and cheap ($33) drone and see what happened. We got some vague data, but the drone didn't get over a few meters high due to the high load. Zip ties provided some protection on takeoff/landing.

Our initial test flight with some quick plots in the background.

Our initial test flight with some quick plots in the background.

After playing we though it would be fun to do this on a drone with some more power. I grabbed a $55 drone (Syma X5C) on eBay and gave it a shot. After a couple of test flights I just couldn't get the bluetooth link to stay connected at the distances I wanted (50m).

My breakout and the bean attached to the top of the drone body.

My breakout and the bean attached to the top of the drone body.

I added a kludge that wrote data to an SD card using the OpenLog. It was extra weight since I needed two more coin cell batteries, but the drone turned out to be able to carry it to 45 m once or twice. Then the drone looses signal and shakily falls out of the sky until I can get control again. While inspiring me to drool over more advanced drones, I did get some interesting data! Some of the plots are rather small in web-view, but click on them to expand. I just didn't want a bunch of individual figures making the post scroll forever.

2015-07-27 19.17.44

First I'll show my first SD logged flight(s). Below is the altitude plot (derived from the barometric pressure sensor on-board).

A few up/down flights of the drone. The ascent in the grey box will be examined in detail.

A few up/down flights of the drone. The ascent in the grey box will be examined in detail.

If we take the highest and most constant climb rate ascent (gray box) and look at the temperature/dewpoint data we see rather clean results!


It was a dead still evening, just before sundown. Without any mechanical mixing,  we see radiation from the ground producing a temperature inversion (temperature increases with height here). We also see a nice dew point trend to drier air as we ascend. For fun, I calculated the lapse rate. This just means how fast the temperature changes with height. Plotting the data and fitting a line we get about +11 degrees/kilometer of height. A reasonable number. (Perhaps coincidentally about the negative of the typical dry adiabatic lapse rate? It's been too long and I didn't ever do much near ground meteorology. Thoughts appreciated.)


The next evening, a very similar setup without wind, I did another sounding that got up to 45 meters. On this flight I noticed that the bumps in the temperature and dew point trends match rather well with the bump in my ascent rate. Since this drone isn't programmable, I do this by hand which is tricky to judge. It probably has to do with the sensors needing a lot of settling time to equilibrate to their surroundings (a couple of seconds). Maybe flying small circles on the way up is a solution. I also have the video from this flight if you're curious what it looks like. Nothing too interesting, but the uncontrolled descents are rather exciting. I've read about hacking better antennas on this drone for more range, so that's a thought. Before I get it much further away I want to do it in a large field to decrease the risk from a runaway drone. If this proves to be interesting enough, maybe a drone update will be in order. They are pricey though!

Flight 2 data

Flight 2 data

Open Science Pt. 2 - Open Data

For the second installment in our summer open science series, I’d like to talk about open data. This could very well be one of the more debated topics; I certainly know it always gets my colleagues opinions exposed very quickly in one direction or the other. I’d like to think about why we would do this, methods and challenges of open data, and close with my personal viewpoint on the topic.

What is Open Data?

Open data simply means putting data that supports your scientific arguments in a publicly available location for anyone to download, replicate your analysis, or try new kinds of analysis. This is now easier than ever for us to do with a vast array of services that offer hosting of data, code, etc. The fact that every researcher will likely have a fast internet connection makes most arguments about file size invalid, with the exception of very large (100’s of gigabytes) files. The quote below is a good starting place for our discussion:

Numerous scientists have pointed out the irony that right at the historical moment when we have the technologies to permit worldwide availability and distributed process of scientific data, broadening collaboration and accelerating the pace and depth of discovery…..we are busy locking up that data and preventing the use of correspondingly advanced technologies on knowledge.

- John Wilbanks, VP Science, Creative Commons

Why/Why-Not Open Data?

When I say that I put my data “out-there” for mass consumption, I often get strange looks from others in the field. Sometimes it is due to not being familiar with the concept, but other times it comes with the line “are you crazy?”  Let’s take a look at why and why-not to set data free.

First, let’s state the facts about why open data is good. I don’t think there is much argument on these points, then we’ll go on to address more two-sided facets of the idea. It is clear that open data has the potential to increase the friendliness of a group of knowledge workers and the ability to increase our collaboration potential. Sharing our data enables us to pull from data that has been collected by others, and gain new insights from other’s analysis and comments on our data. This can reduce the reproduction of work and hopefully increase the numbers of checks done on a particular analysis. It also gives our supporters (tax payers for most of us) the best “bang for their buck.” The more places that the same data is used, the cost per bit of knowledge extracted from it is reduced. Finally, open data prevents researchers from taking their body of knowledge “to the grave” either literally or metaphorically. Too often a grad student leaves a lab group to go on in their career and all of their data, notes, results, etc that are not published go with them. Later students have to reproduce some of the work for comparison using scant clues in papers, or email the original student and ask for the data. After some rummaging, they are likely emailed a few scattered, poorly formatted spreadsheets with some random sampling of the data that is worse than no data at all. Open data means that quality data is posted and available for anyone, including future students and future versions of yourself!

Like every coin, there is another side to open data. This side is full of “challenges.” Some of these challenges even pass the polite term and are really just full-blown problems. The biggest criticism is wondering why someone would make the data that they worked very hard to collect out in the open, for free, to be utilized by anyone and for any purpose. Maybe you plan on mining the data more yourself and are afraid that someone else will do that first. Maybe the data is very costly to collect and there is great competition to have the “best set” of data. Whatever the motivation, this complaint is not going to go away. Generally my reply to these criticisms goes along the lines of data citation. Data is becoming a commodity in any field (marketing, biology, music, geology, etc). The best way to be sure that your data is properly obtained is to make it open with citation. This means that people will use your data, because they can find it, but provide proper credit. There are a number of ways to get your data assigned a digital object identifier (DOI), including services like datacite. If anything, this protects the data collector by providing a time-stamp of doing data collection of phenomena X at a certain time with a time-stamped data entry. I’m also very hopeful that future tenure committees will begin to recognize data as a useful output, not just papers. I’ve seen too many papers that were published as a “data dump.” I believe that we are technologically past that now, if we can get past "publish or perish," we can stop these publications and just let the data speak for itself.

Another common statement is “my data is too complicated/specialized to be used by anyone else, and I don’t want it getting mis-used.” I understand the sentiment behind this statement, but often hear it as “I don’t want to dedicate time to cleaning up my data, I’ll never look at it after I publish this paper anyway.” Taking the time to clean up data for it to be made publicly available is when you have a second chance to find problems, make notes about procedures and observations, and make it clear exactly what happened during your experiment (physical or computational). I cannot even count the number of times I’ve looked back at old data and found notes to myself in the comments that helped guide me through re-analysis. These notes saved hours of time and possibly a few mistakes along the way.

Data Licensing

Like everything from software to intellectual property, open-data requires a license to work. No license on data is almost worse that no data at all because the hands of whoever finds it are legally bound to do nothing with it. There is even a PLOS article about licensing scientific software that is a good read and largely applies to data.

What data licensing options are available to you are largely a function of the country you work in and you should talk with your funding agency. The country or funding agency may limit the options you have. For example, any US publicly funded research must be available after a presidential mandate that data be open where possible “as a public good to advance government efficiency, improve accountability, and fuel private sector innovation, scientific discovery, and economic growth.” You can read all about it in the White House U.S. Open Data Action Plan. So, depending on your funding source you may be violating policy by hoarding your data.

There is one exception to this: Some data are export controlled, meaning that the government restricts what can be put out in the open for national security purposes. Generally this pertains to projects that have applications in areas such as nuclear weapons, missile guidance, sonar, and other defense department topics. Even in these cases, it is often that certain parts of the data may still be released (and should be), but it is possible that some bits of data or code may be confidential. Releasing these is a good way to end up in trouble with your government, so be sure to check. This generally applies to nuclear and mechanical engineering projects and some astrophysical projects.

File Formats

A large challenge to open data is the file formats we use to store our data. Often times the scientist will use an instrument to collect their data that stores information in a manufacturer specific, proprietary format. It is analyzed with proprietary software and a screen-shot of the results included in the publication. Posting that raw data from the instrument does no good since others must have the licensed and closed-source software to even open it. In many cases, the users pay many thousands of dollars a year for a software “seat” that allows them to use the software. If they stop paying, the software stops working… they never really own it. This is a technique that the instrument companies use to ensure continued revenue. I understand the strategy from a business perspective and understand that development is expensive, but this is the wrong business model for a research company. Especially considering that the software is generally difficult to use and poorly written.

Why do we still deal in proprietary formats? Often it is because that is what the software we use has, as mentioned above. Other times it is because legacy formats die hard. Research groups that have a large base of data in an outdated format are hesitant to update the format because it involves a lot of data maintenance. That kind of work is slow, boring, and unfunded. It’s no wonder nobody wants to do it! This is partially the fault of the funding structure, and unmaintained data is useless data and does not fulfill the “open” idea. I’m not sure what the best way to change this idea in the community is, but it must change. Recent competitions to “rescue” data from older publications are a promising start. Another, darker, reason is that some researches want to make their data obscure. Sure, it is posted online, so they claim it is “open”, but the format is poorly explained or there is no meta-data. This is a rare case, but in competitive fields can be found. This is data hoarding in the ugliest form under the guise of being open.

There are several open formats that are available for almost any kind of data including plain text, markdown, netCDF, HDF5, and TDMS. I was at a meeting a few years ago where someone argued that all data should be archived as Excel files because “you’ll always be able to open those.” My jaw dropped. Excel is a closed, XML based, format that you must have a closed-source program to open. Yes, Open Office can open those files, but compatibility can be sketchy. Stick to a format that can handle large files (unlike Excel), supports complex multi-dimensional data (unlike Excel), and has many tools in many languages to read/write it (unlike Excel).

The final format/data maintenance task is a physical format concern. Storage media changes with time. We have transitioned from tapes, floppy disks, CDs, and ZIP disks to solid state storage and large external hard-drives. I’m sure some folks have their data on large floppy disks, but haven’t had a computer to read them in years. That data is lost as well. Keeping formats updated is another thankless and unfunded task. Even modern hard-drives must be backed up and replaced after a finite shelf life to ensure data continuity. Until the funding agencies realize this, the best we can do is write in a small budget line-item to update our storage and maintain a safe and useful archive of our data.


The last item I want to talk about in this already long article is meta-data. Meta-data, as the name implies, are data about the data. Without the meta-data, most data are useless. Data must be accompanied by the experimental description, relevant parameters (who, when, where, why, how, etc), and information about what each data item means. Often this data lives in the pages of the laboratory notebooks of experimenters or on scraps of paper or whiteboards for modelers. Scanners with optical character recognition (OCR) can help solve that problem in many cases.

The other problems with meta-data are human problems. We think we’ll remember something, or we don’t have time to collect it. Anytime that I’ve thought I didn’t have time to write good notes, I payed by spending much more time after the fact figuring out what happened. Collecting meta-data is something we can’t ever do enough of and need to train ourselves to do. Again, it is a thankless and unfunded job… but just do it. I’ve even just turned on a video or audio recorder before and dictated what I’m doing. If you are running a complex analysis procedure, flip on a screen capture program and make a video of doing it to explain it to your future self and anyone else who is interested.

Meta-data is also a tricky beast because we never know what to record. Generally, record everything you think is relevant, then record everything else. In rock mechanics we generally record stress conditions, but never think to write down things like temperature and humidity in the lab. Well, we never think to until someone proves that humidity makes a difference in the results. Now all of our old data could be mined to verify/refute that hypothesis, except we don’t have the meta-data of humidity. While recording everything is impossible, it is wise to record everything that you can within a reasonable budget and time commitment. Consistency is key. Recording all of the parameters every time is necessary to be useful!

Final Thoughts

Whew! That is a lot of content. I think each item has a lot unsaid still, but this is where my thinking currently sits on the topic. I think my view is rather clear, but I want to know how we can make it better. How can we share in fair and useful ways? Everyone is imperfect at this, but that shouldn’t stop us from striving for the best results we can achieve! Next time we’ll briefly mention an unplanned segment on open-notebooks, then get on to open-source software. Until then, keep collecting, documenting, and sharing. Please comment with your thoughts/opinions!

Happy Leap Second Day!

I'm currently in the process of getting part 2 in our open science series prepared, but wanted to drop a quick note saying happy leap second day! In just a few hours we will have our 26th leap second! The last minute of today (UTC) will have 61 seconds to make up for difference in our atomically derived time system and the imperfect system that is the Earth's rotation. The clock will read 11:59:59, 11:59:60, 12:00:00. Unusual eh? You can watch the leap second online at time.gov, spend your leap second watching a random one second video at spendyourleapsecondhere.com, or watch it nerd-style on your GPS NMEA feed.

If you want to know more about leap seconds and the wacky world of time keeping systems, I encourage you to listen to our episode on time-keeping on Don't Panic Geocast. We put a lot of time into researching that show and had a lot of fun learning about how complex time really is. Happy leap second day everyone!