Why the name Eagle?  Good question.  I’ll explain in a bit.

You know it’s good luck when the day before the launch, you get this comic sent to you by your mom:

What’s new with this flight?

This flight is the second launch of basically the same payload as my first flight, however with some modifications:

• INA219 voltage meter reading the Pi’s input voltage and current.  (I wanted to monitor the battery voltage before the regulator, but I didn’t get time to wire it up)
• Replaced UBEC voltage regulator with a LM2577 regulator which is a boost-buck combination regulator, rated to boost voltages as low as 4V.
• 6 AA batteries instead of 4.  Why?  In some of my tests, the voltage regulator was really unreliable when input voltage was around the output voltage (5V).  It worked more reliably in tests when the input was much higher.  6 batteries yielded plenty.
• Lots of code changes – highlights:
  • Read the sensors every second and write to disk (even though we only TX every ~20 seconds since it’s 50 baud slow)
  • Keep the UART output buffer low so that the transmitted message is not 2 minutes old (a problem on the last flight where BUZZ appeared to be always 2km ahead of SAM on the map)
• Pi camera attached to the payload side rather than the top, to compare it against the Canon A810.  Spoiler alert – the Pi pictures are much better.
• Hwoyee HY-750 balloon instead of a HY-500 (to go higher and carry more weight)

Launch Crew

Chase car driver: Barry Tucker
Pretending to know it all: Patrick van Staveren (me)
Backup radio operator: Marcus Daniels
Moral support: Ray Pasko

Launch Site

Steve Randall hosted the launch in Elsworth which is just outside Cambridge.  During the same weekend the Big EARS rocketry event was going on from the same site, so we had to keep a bit of distance from the rocket launch pads.  There were some huge rockets being launched – with bodies at least 20cm in diameter and taller than me – some of which had engines that made us catch our breath.  Lots of fun to watch!

Big thanks to Steve!  Double thanks for loaning me his HL1 tracker to use as a backup tracker.  Good news is that I didn’t need it – but given my fun with voltage regulators…yeah.  Good idea.

The weather was absolutely perfect – blue skies as far as we could see and mid-20 (celsius) temps.

 

Voltage regulator tests prior to launch

Back in April I bought a 10kg box of dry ice to test out some voltage regulator options.

I tested three voltage regulators:

• UBEC regulator from last flight
• LM2577 adjustable boost-buck regulator, rated for 4V up
• XL6009 adjustable boost-buck regulator, rated for 3V up

What I learned:

• Dry ice is fun
• Energizer L91 batteries at low load seem to increase in voltage as the temperature drops down below 0 until about -30C.  It’s only colder than that that the output voltage started to drop from the battery pack.
• The UBEC regulator itself decreases output voltage as it’s temperature drops.  You can see a profile here.
• A Raspberry Pi doesn’t like 17 volts.  Don’t do it.
• The XL6009 regulator seemed great at low temperatures and input voltages as low as 4V, however it had a fluke around -30C where the output voltage would spike from 5V to 7V!  Oddly enough the Pi and all the on-board electronics handled it fine…but I didn’t feel comfortable flying it.
• The LM2577 was OK with a sufficient input voltage, but not great when the input voltage was low.   I tested with 6x AA’s and it was solid.
• Making arbitrary data (in this case, digitemp readings) available for prometheis node-exporter is very easy.

By the end, I had both my tracker wired up as well as a second Pi with digital temperature sensors on it and it all logging to Prometheus so I could draw nice graphs in Grafana.  But it was a wiring mess (fun!)

Flight

You can watch a video of the launch!  Thanks Marcus!

We flew from Elsworth up to March.  Flight track on Google Maps.

The flight path this time (compared to February) was rather short – only a 30-40 minute drive.  The actual path across land was about 32km which is really not far.  If only there were such roads…

The balloon burst earlier than predicted.  The estimated burst was 30,600m and the actual max altitude was about 27,700m.

I had great radio reception on the ground, which is good, because I left my SMA to MCX RF adapter at home, meaning that I couldn’t plug my yagi antenna into my best SDR radio.  Good news was that one of my cheap mag mount antennas seems to get good signal quality with 70cm waves (which is surprising given it’s length of about 147mm – a bit short for this frequency, I think? What do I know about radio!)

Recovery

We lagged around a while at the launch site talking to Steve, and had lunch at a pub in Elsworth, so we were late to chase.  Next time I’m going to pack sandwiches for the drive.

The payload landed at March Golf Club.  I can’t recommend it any higher as a landing site!  One of my fears in getting started with HAB was having to knock on random people’s doors and explain why I want on their private property to retrieve my mysterious electronics equipment.  Andrew at the March Golf Club happily showed me to the payload which he had previously moved off a fairway so that it wasn’t in the way.  It doesn’t get any easier than this for recovery.

Secondary Experiment: ADS-B receiver

A few months ago I had an idea.  As I’ve been running an ADS-B tracker at home sending data to Flightaware, Opensky Network, ADSB Exchange, and Flightradar24, it’s helped me learn a bit about radio waves.  Realizing the limitations of where I live and the fact that I can’t mount a giant mast on the top of my flat to get better reception, I wondered, how far away can I receive ADS-B signals from a HAB payload?  Surely at 10km up you’ll get amazing reception, right?  I wanted to try that.

However I didn’t get until the night before this flight to actually build the receiver for it.  Since I didn’t trust it to not interfere with the code I was running on the main tracker, I set up an independent Pi computer, independent power source, and a mini SDR to receive ADS-B data.  I threw it together in about 90 minutes – so I hadn’t tested it much.  But it was worth a shot and we flew it.

It worked – however there were a few glitches.  I’m using dump1090-mutability to track planes, but you have to log it somewhere, right?  So I used this hack to log data.  Where does it log data by default?  /tmp.  What does a modern Linux OS do with /tmp on boot these days?  Erase it.  Yep, I wrote the data into /tmp, and when the tracker computer hit the ground, it rebooted (as did EAGLE) and it overwrote the data.  But – there’s always a catch!  Unlinking a file on a modern filesystem means the data is probably left there, right?  scalpel to the rescue!  I managed to recover about 95% of the data, only losing about 15 minutes of flight time.

In the end, the results aren’t amazing.  I think part of the problem is that socket30003.pl didn’t seem to log everything – don’t ask me why.  According to the CSV that was written, I captured 297 ADS-B positions from 18 distinct aircraft.  Meh.  I get that many positions every single second from my home station.

I think the socket30003.pl script didn’t log everything.  Looking at dump1090’s hourly stats output shows that in one hourly band during the HAB flight it tracked 200 distinct aircraft.  I just didn’t get that much logged to disk.

But it does mean I can make this cool map:

Next time need to set up better data logging, actually retain the data, and also deal with time synchronization.  In the mean time I might give the payload a ground test just to see how it performs compared to my regular ADS-B station.

The Unexpected

What didn’t go as planned?

Burst altitude: 27,700m, lower than expected

The calculated (read: estimate!) burst altitude for this configuration was about 30,600m.  Here’s what numbers we used:

Did we overfill it?

Well, the helium cylinder is a N10 which contains 2.6 cubic meters of helium, so we couldn’t have put much more in than the calculated 2.482 above?

The balloon was a bit heavier than last time (750 grams, vs 500 last time) however the balloon didn’t have a uniform burst like last time.

I think the balloon just wasn’t perfect, and it split at just one spot rather than shredding like what clearly happened with the last one.  Opinions in the launch group were divided (was it extra UV rays because it was a sunny day?) but my thought is that when I first pulled the balloon out of the bag, I did so with a sweaty hand.  Maybe that weakened the latex?  Who knows.

bme280 sensor for temperature, pressure and humidity

This sensor yielded some fun data from the last flight, because it’s measuring something that my brother-in-law Erik Tollerud pointed out is something we can model with some rather simple formulas.  Unfortunately the sensor didn’t work for this flight.

Some time within 30 minutes after power on, before the payload even took flight, the sensor readings in my code started yielding constant data every read.  The actual sensor is on an I2C bus, and is read once per second.  I can’t figure out why, but the sensor started returning the same data every time.  Further testing required.

Flight Data

This flight I recorded high resolution sensor data every second, in addition to transmitting back to the ground on RTTY every ~20 seconds.  Unfortunately less fun since the bme280 data is broken, but it’s still fun to analyze.

Have a look at the sheets yourself including some great charts.  Times are in UTC just to confuse you (the photos below are in BST).  In particular interest:

Velocity vs. Internal (LM75) Temperature:

Temperature vs. Voltage

(this is output of the voltage regulator, so shows how it performs at negative crazy C!)

Interesting one that I’m still messing with is this graph of ascent velocity. It’s hard because the GPS isn’t perfectly consistent, so you have to smooth the data out.  Looking at this you might conclude that we overfilled the balloon as the ascent velocity appears more towards 6m/s when we shot for 5m/s, however the ascent velocity decreases…and then increases later?  I expect it to increase slightly as the atmosphere thins and the balloon has less mass to move through…but I didn’t expect it to decrease for the first half of the ascent.  Anyone understand why?

Photos

We got some great shots.  Very interestingly, I think the Pi camera is taking better photos than the Canon A810.  I suppose I shouldn’t be surprised.

It was such a beautiful day that you could see the ground clearly.  Bonus points for spotting the bit of shredded balloon in the photo.

We even snapped a few photos of March where we landed.

You can check out the full photo roll, including launch site photos, videos, and all the photos from the launch (about 700 of them.)

Ideas for next time

• ADS-B receiver: so many tests to do.  Test the ADS-B tracker and see if the antenna I have on it gets decent quality on the ground?  Try another method other than socket30003.pl?
• Time synchronization to the Pi host would really help log analysis.
  • Perhaps for a non-connected device like the ADS-B tracker, it could just connect via wifi (to my mobile) while on the ground to get an initial time sync? From that I could even SSH in and check data reception before launching…
• Need to get the tracker logging data in a more friendly format for post processing.
• Don’t fly the Canon A810 camera any more, it’s a waste of weight.
• Bring gloves.

Finally

Well what was fun.  Conclusion: lets do it again.  Sometime soon.

So why name it EAGLE?

When we were kids, my Mom named her van “Eagle”, because she liked birds.  That van became one of the first vehicles I drove when I was learning to drive.  But the best bit is – when the van would arrive home, and when my balloon landed, I had the excuse to say “The Eagle has landed.”