HAB flight 4 – “I’m back in the USA…”

Posted on September 23, 2024 by Trick

It’s been five years since my last HAB flight. The payloads have been moved across the world in a shipping container,  grown dust, moved from box to box, and even parts pillaged for other projects.  “hatTrick” and “EAGLE” haven’t broadcast in five years…until this year!  2023’s success in chasing radiosondes (7 so far) motivated me to want to get back to launching my own.  This time without any Steve or Dave guard rails to avoid me messing it up.  Which we did – we made a brilliant mess of an otherwise successful launch on September 7th, 2024.

This is a very long write-up to detail how I got here from the last flight, about the flight itself, and detail on all the trackers.

Table Of Contents

Building Up To The Flight

One thing I was sure of: I wanted to re-fly both hatTrick and EAGLE given that they are “flight proven” trackers from previous flights (1, 2, 3).  They’ve been there and back again and proven themselves.  While I want to also experiment, I don’t have a huge local community to track like I did with UKHAS in the UK – and my flights in the UK I also had the Dave/Steve safety net of them attaching one of their super-light payloads to the train as a backup tracker.  This time I’m on my own.

EAGLE sat on my shelf proudly for years, but hatTrick had been partially disassembled for a trip to New Zealand where I considered flying it, and parts of it had gone in different boxes which I had to find.  I found them all, found their Raspberry Pi CSI cables both suspiciously missing (I have a habit of breaking them and not keeping stock).  I powered them on and they transmitted signals.  I had to go back to my emails from 2019 to remember what frequency and encoding they were set to!  The Raspberry Pi and Lora Hat I was using had parted ways years ago and I had to re-build the ground station, but that was easy enough.

A lot has changed in five years; habhub has been re-birthed as Amateur Sondehub. No one uses dl-fldigi anymore and apps have been updated.  Radiosonde reuse has become everyday, and chasers have huge boxes full of them.  Horus 4FSK has become commonplace in that time as well!

In the months leading up to launch, I prepared a bunch more things:

Scouting launch sites was interesting. I had tried to liaise with the Illinois DNR over the summer to see if they had any permit requirements, and while people there found it fascinating, I never received a straight answer on whether they had any requirements or not.

I had guesstimated from looking at rough historical flight data for NWS sondes from Davenport, IA for September each year that the flight would travel a fair distance ESE on a given day – 58 miles ESE was the gauge I used. I ran scenarios with a couple of different launch sites, estimating driving distance from my home given the guessed launch path to lead me to the launch site. This was useful, but overly scientific. It did give me a good bit of information to write a flight announcement to encourage friends, family, and new community members to join the launch. I also wrote a technical version of it just for hams for how to configure their radios to receive which people found useful.

Differences Observed from UK to US

Community

The UK is, geographically speaking, rather small.  Lots of radio amateurs live within the south of England and enjoy tracking balloons, so if you’re doing a launch in the area, you’re basically guaranteed a crowd of listeners.  The US is more spread out – there are just as many hams and balloon nerds, but most of them will be out of range of your balloon.

In the UK I made all my connections through the UKHAS mailing list; in the US I’ve made connections through the GPSL mailing list and interestingly connected with some fellow radiosonde chasers simply by looking up each other’s callsigns on the Internet.  One of whom tracked and chased my balloon which was a pleasant surprise!  If you tracked any of my payloads and would like to get in touch, you can contact me here.

I’ve also not found the selection of Web SDRs here that I had found in the UK; often if a flight was in the air and out of range, you could find a Web SDR on 70cm to listen to it.  Most if not all of the Web SDRs here in Illinois seem to be focused on HF.

Radio license

The UK had an explicit rule against amateur radio permissions while airborne, and a license-exempt ISM band around 433mhz. In the US, this band requires a radio license.  It’s incredibly easy to get the basic technician license which due to the pandemic is now possible entirely remotely.  To get my license in the UK, I had to schlep across London, solder a circuit, and take an exam.  In the US it’s just an exam.  Reconfiguring my trackers to transmit my callsign was easy enough.

APRS

It seems that the defacto standard for trackers in the US is APRS.  Since amateur bands are legal airborne, this isn’t a bad idea, but I’ve never built an APRS tracker.  I had enough trackers going on that I didn’t bother with an APRS tracker for this flight; I may in the future (I have all the parts to build one in a box, just didn’t find the time, yet!)

Rules & legality

The UK required permission from the CAA for the launch site, and a NOTAM, for all flights.  This made it a bit challenging to sort out a launch site, so I borrowed others’ regularly used launch sites for simplicity.

In the US, regulations are not simple either – however if you’re under 4lbs / 1.8kg and follow a couple of other easy to meet regulations, you can fly “exempt.”  You don’t need any prior authorization from the FAA, meaning that you can use any launch site assuming you cooperate with any requests from  the owner.  Public parks are great.  Filing a NOTAM is not required but a good idea, so I did one (even though we didn’t quite follow it!)  It was easy.

The US NOTAM Process

There’s a lot of stress around NOTAM filings for me. I don’t want a FAA officer to say “hey you can’t do that” and deny the NOTAM, so I was hesitant at first.  Having done it, it’s a breeze, and I’ll do it in the future. I mostly followed Project Traveler’s NOTAM guide with a couple of modifications – the operator was happy to take the launch location in latitude/longitude, and also wanted to know the actual real intented altitude (which was 100,000 ft in my case).  They do seem to care about above FL600.  The phone number is the same: 877-487-6867; I was on hold for 2 minutes to connect to an operator, he was entirely professional, patient and kind, and the whole process took maybe five minutes.
They took my phone number and initials, but no further identification was required.
I recommend you file a NOTAM even if not required.  It’s easy, and fun to be able to look yourself up a couple of hours later on the FAA NOTAM search.

The Flight Story

Week leading up (T-7 days)

The flight path prediction varied wildly in the week leading up to flight.
I had originally picked a Illinois State Park called Franklin Creek as my planned launch site, with a backup plan in Dixon, IL.

The CUSF/Sondehub Predict tool supports predictions up to 7 days out from a given launch time, and at first prediction 7 days out this showed the balloon flying due east and landing in St. Charles, IL at the very western suburbs of Chicago. Not great; it’s a very populated area. As the days progressed, the landing site shifted south, to Joliet, and then pulled further east of Joliet. Interestingly, the hour-by-hour change was at least a couple of miles different, meaning that launch timing was important to keep an eye on. The GFS model which powers the predictor tool is updated every 6 hours. At about 4 days out from launch time the landing area became reasonably consistent. I kept a log of the predictions I ran each day.

At T-2 days I filed a NOTAM for launch from Franklin Creek but there was a glint in my eye that we’d move a couple of miles west to a park in Dixon, IL. The forecast of ground wind speed of 11mph wasn’t encouraging, but I didn’t cancel the launch. Instead I worked on my launch procedure and checklist doc (which maybe I’ll share some day), packed up payloads and everything into boxes, etc. I picked up the cylinder of helium 3 days before launch from a local party balloon store who was actually fine with me keeping it for a month or “as long as I need.” We’ll get onto helium woes in a minute.

As the week went on, the final flight weight got honed in a bit more. I added a GoPro camera (101g) but subtracted some fluff I had previously estimated so my weight went up from 776 grams to 838 grams – enough to change the calculations and flight profile slightly, but not huge.

Launch Day

01:00 CDT, T-10 hours from launch

That’s what time I went to bed. I was up late, packing payloads, putting finishing touches on the launch procedure document and packing lists which will pay off at the next launch. 1 AM was a common time in the weeks leading up to the launch, as late nights are often the only real time I have to myself with two young kids at home! It’s certainly not good for my health…

06:00 CDT, T-5 hours from intended launch

On launch day I woke at 6 am, T-5 hours before target liftoff time, made a pot of coffee, and checked the prediction. The landing spot was too close to a combo of stress – a nuclear power plant and a national guard training base:

A “fouled chute” – a faster than planned descent that happens from time to time – put the payload about a mile from the training area. (!!)

Just wait until you see where it landed.

The alternate launch site in Dixon, IL looked perfect. I SMS’d the launch crew, packed the car, and left the house 45 minutes later than planned. The launch would be delayed a bit. I had estimated two hours at the launch site to prep and test, but an hour late liftoff would work fine from a timing and prediction standpoint.
It took me an hour to drink coffee, run a dozen hypothesis about alternate launch sites, make the decision, nervously drink more coffee, document the decision, and send the messages to the launch crew. After which I still had a stack of boxes to get in the car and a short list of odd items to hunt through my house to find.

09:45 CDT, T-75 minutes from target launch time

We all met up at the launch site:

  • Myself, Sarah, and our two kids
  • Adam from SSHC
  • Spencer from Mintel, and his friend Joel

We arrived at the launch site in Dixon which I’ll post a satellite image of here with fun commentary:

I hadn’t noticed those big power transmission lines that cross the river! Fortunately, they were off to the side, and the wind was blowing parallel to them, so clearance was not a concern. The only launch clearance concerns were a line of trees towards the water, and some flood lights on the baseball diamonds – all easily avoided. The tree line to the north provided perfect shelter from the ~10mph ground winds; we set up shop at the blue X, bothered no one for the hours we were there, and it worked perfectly. We had one spectator who pulled out a lawn chair and watched us prep.
It probably took us 45 minutes just to say hi in the parking lot, walk around and scout launch spot options and contingency plans, and pick the X spot where we’d set up and launch from.

I spent some time in the parking lot (50m walk away from the launch site) setting up a tracking antenna, laptop, power supply, and radio in Spencer’s car so we’d have a second chase car with an independent data feed in case we split up (say if one of my kids needed something!). I put some more antennas on my roof, pulled wires, and powered up both EAGLE and KD9PRC-4FSK1 (DFM17) in the parking lot on spare batteries just to make sure we had signal. We then hauled all the boxes of stuff over to the launch site and set up shop; Spencer brought a folding table which was a great idea. He brought donuts and coffee too, which turned out to be absolutely essential as the launch prep ended up taking hours.

10:45 CDT, T-15 minutes, no way in hell we’re launching on schedule :)

I fired up all the receiving radios and trackers using spare batteries. I realized that I didn’t have a lot of a plan for what order to string them up in or exactly when to close up payload boxes. So I got the trackers laid out on the ground, decided an order, running on spare batteries, and tested signal on everything end to end until I was happy.

My lawn mower battery power adapter built from this model was very helpful: over at the launch site far from the car I had a laptop and half a dozen electronics gizmos all powered by a 250Wh battery converted to 110V AC which did not run out of juice.

11:15 CDT, T+15 minutes, which turned out to be T-2.5 hours from launch

We started the balloon fill. Adam had brought some nice soft gloves for us to wear, which was a great addition to keep the balloon safe. The minute I attached my recently built inflator to the cylinder and started to fill, I knew we were in trouble: the PSI reading on the cylinder as we started to fill was only 1400 or 1600 PSI. I started yelling out PSI numbers as the cylinder rapidly drained. 1000. 800. 500. 200. Done. The balloon had some lift, but nowhere near the required neck lift. Fail #1 of the day. We needed about 90 cu. ft. of helium and did some guessing with the scale and figured we had only about 60 in there. The balloon did not look puffy and full, it looked sad and still slightly wrinkly:
sad balloon
A bit of googling and phone calls and we found that Hobby Lobby 15 minutes away sells $50 packs of balloons including 14.9 cu ft of 80% helium in a canister made by Balloon Time. At 80%, we needed 4 of them to hopefully yield another 40 cu ft of lifting helium gas; 4 canisters should be about 48. Which was a penalty of $220 in the end. Ouch. Hobby Lobby ended up having only one in stock, but Walmart had half a dozen on the shelf. Sarah drove and bought helium and fed the kids while the rest of us sat at the launch site, slowing getting burnt in the sun, taking turns guarding the balloon from the odd gust of wind.

13:15 CDT, T+2h15m intended launch, T-1.5 hours until actual launch

Sarah arrived with four Balloon Time boxes, two kids who were happier to have some lunch in them, and we started the fill. It was a goofy procedure of pinching the neck of the balloon between cylinder changes, moving the hose to a new cylinder, and taping it on – but it worked and we didn’t leak any that we observed. The tiny cylinders filled slowly, but surely. It took about an hour to fill, using ~3.5 of the little cylinders, to get to our target neck lift. Now the balloon looked healthy!

I ran a couple more flight predictions, but at this point we were both launching late, and with an unknown volume of gas. I expected the balloon would burst early, maybe as early as 25km instead of the target 30.5km, and predictions looked OK. Still in farm fields!

14:15 CDT, T-35 minutes from launch

Now the balloon was full, we’re all so tired, and it’s time to put in the non-reusable Energizer Ultimate Lithium batteries into everything, confirm telemetry, tape up the payloads, string them up, and get ready for liftoff. This took another 30 minutes during which I remembered an important checklist item:

Zip tie the batteries in hatTrick and EAGLE so the batteries don’t pop out on landing.

I remembered this after hatTrick was already sealed up. We cut the payload train off it, cut duct tape, zip tied, and fail #2 of the day hit: the Raspberry Pi camera CSI cable came unplugged. Telemetry continued to feed, but I didn’t notice that SSDV was offline.

14:50 CDT: Liftoff!

Liftoff! We cleared all obstacles easily. We watched the balloon for a few minutes, and then started packing up. I lost telemetry for most of the payloads, because my big roof mounted antennas were on the car, and the receivers were on the ground with no antennas at all. I found some stubby antennas for one of them, but EAGLE and hatTrick lost telemetry for a couple of minutes until I got the radio receivers into the car.

On returning to the car and rigging up roof mounted antennas to trackers, we found that the radio I’d put in Spencer’s car was not receiving any data.  Investigation found that the SMA-to-MCX adapter was broken (the tiny pin inside broke).  I don’t like MCX connectors.  Unfortunately had no spares on hand despite packing an extra of seemingly everything.  It was only a week later that I recalled that I had a spare SMA SDR in the bag, and my Kenwood TH-F7 can receive the Horus 4FSK signal…could’ve used either of those to receive!  Next time.

We set course for a way-point in Ottawa, IL, towards the predicted landing site.
As we drove through Mendota, IL, a fellow ham and radiosonde tracking extraordinaire KB9RKU messaged that he would join the chase!

We had upwards of 100 contacts on Meshtastic, and people had fun with it. Every time I received a downlink message from the python script on the Meshtastic payload, I giggled a bit. I sent it silly messages in reply. I watched EAGLE start to send NOFIX telemetry during the drive, and fiddled with my LoraBluetooth receiver whose rooftop antenna I broke in the haste of the chase, so it only had a little stubby antenna to try and work with.

16:30 CDT: Waiting for burst

The balloon flew much higher than I could have hoped for; had this been pure helium, I bet it would’ve seen 32km or more. It burst at 30,984 meters! Burst was at 16:35. We had been sat in a KFC parking lot in Ottawa watching the telemetry come in, getting a quick bite to eat, observing burst, and then waiting for the prediction to update with a new landing spot.

16:55 CDT: Watching it descend

We drove a mile or two north of the predicted landing spot to watch the best thing of all: the payload descending! We parked on the side of a road, and looking straight up, caught a view of it up at about 3km. The bright orange and green parachute stood out well in the sky. Someone must’ve taken a video, but I did not. We watched it fly straight over us, parallel to the road we were on, directly for a rare patch of trees. If we got lucky, it’d land in the road…

17:07 CDT: Landing

No luck. Sadly, it landed up in a tree, far back in private property. We had telemetry from all four payloads after landing and great signal indicating that it was up in a tree. We never caught a glimpse of the payloads. They may return some day.

Wrapping Up the Flight

It’s sad to return home without payloads. Good news is that the DFM17 tracker performed excellent, and I have another four DFM17s here that I haven’t even taken a soldering iron to yet – and they rain from the sky every day. I can probably recover 5 of them this winter when the winds blow them this way.

Next flight? After losing payloads, and not taking home a single photo due to the combination of losing SSDV and also from not recovering the GoPro onboard nor the photos on EAGLE’s SD card…I probably don’t want to launch anything valuable…I’m sad about it all. I’ll focus on fixing the logistical failures (helium in particular) and probably rely on a pair of DFM17s – one to transmit Horus 4FSK continuously, and one to tinker with CATS.radio with a bit of 4FSK as a backup. Maybe a Horus Wenet or another PITS payload for in-flight pictures, but, only if I’m feeling energized. It’d be interesting to focus on a telemetry-only flight. I also have new parts in stock for an APRS tracker, so maybe I’ll throw that together.

The Meshtastic crowd wants another flight and people have already offered to help sponsor a payload, so I’ll be looking to connect with serious folks who want to fly a Meshtastic node – one that’s well tested, doesn’t crash when frozen (bonus points if it gets tested with dry ice), and need to keep an eye on which GPS chips are in use so we make sure they are in “flight mode”.

The Failure List (ahem, the Opportunities To Learn List)

  1. Helium. Figure out what happened – is this not a 100 cu ft cylinder? Was it under-filled from the store? Was it a helium/air mix?  Does anyone know what size cylinder I have pictured, and what it’s full pressure should be?
  2. EAGLE: why on earth did it lose GPS fix on ascent? A failure mode not seen on earlier flights.
  3. horusdemodlib telemetry logs: the RTTY payload logs didn’t get captured locally on any of my receivers, only the Horus 4FSK telemetry strings. Is this because we were running two modems / uploaders in parallel, both held open a different file handle to different inodes, so it ended up being a race condition which one gets written last and preserved? If so it’d probably be worth modifying the horus uploader to write separate telemetry files for each payload ID or process ID or timestamps, to avoid this clash. I wish I had the “nofix” data from EAGLE for analysis, but it scrolled off all my consoles and only one copy of it remains – and it’s currently up in a tree.
  4. Tying the payload train together was tedious and error prone; it would be easy to mess this up. Rehearse this.
  5. Payload label – I put a printout of my contact details on the front of a couple of the payloads. Laminate this. Once it rains, the ink will wash away and if it’s recovered by an unsuspecting visitor, it may never find it’s way back to me.
  6. Buy / find a source of better boxes :) The styrofoam box I built for the meshtastic node was crude.
  7. SSDV status got missed: maybe it’s worth having some kind of red-light green-light system which aggregates data from Sondehub and SSDV for expected payloads and shows them in a big bright display on the screen meant to use prior to launch. If any expected payload is offline, or stale for more than a minute, turn it red.
  8. Meshtastic: why did the unit fail and start to reboot loop? GPS max altitude, temperature / voltage drop, or something else?
  9. Meshtastic: log more data on a downlink, in case of losing the payload. Write a MQTT aggregator which uploads data to Sondehub Amateur for the payload, and maybe write something that downlinks data for every new contact made and posts the top 10 active payloads by distance so we can accurately verify when we set a Meshtastic distance record (which we certainly did on this flight – but the evidence is not there.)
  10. Hydrogen as a lifting gas? Why not? How big of a bang could it possibly be to have a balloon of hydrogen blow up?  The scientific response is, of course: fill a little party balloon with hydrogen and blow it up!
  11. Payload mass calculations: I forgot to include the chute in my latest payload weight calculations (it’s only 28 grams anyway) but I also forgot to include any balloon remnants in the descent velocity calculations.  This means that while I calculated 6.8m/s descent velocity, it went a bit faster (looks like 7.5). Not a huge deal, just an observed error.  My ascent velocity was lower than planned; either we weren’t able to quite get neck lift calculated right, or I used a ton of duct tape, or something extra…

Payloads Flown

I went nuts on this flight.  I had two experiments to fly, and I wanted to make sure as hell that if/when something went wrong with a payload or a receiver that I had enough redundancy to be able to track the flight in it’s entirety.  So I flew both EAGLE and hatTrick (LoRa PITS-like tracker) alongside the two new experimental payloads.  Here’s a rundown of each of the trackers that flew.  You can also find some weight data in this sheet if you’re curious how heavy stuff was.

Experiment: DFM17 Horus 4FSK & CATS.radio

In early 2023 I recovered my first few DFM17 radiosondes, and was sad to not be able to find any material progress on a replacement firmware at that point in time.  A couple of weeks later, I found gx1400’s code which needed a lot of work, but was a viable base.  I patched and hacked at it, eventually getting it to transmit CW and APRS, but the code base quickly sprawled out of control and needed a re-think.  I was troubled by how fragile my development setup was, so I worked on making a 3d printed clip to enable solderless programming which I hope someone tries.  I ran out of energy for the code base, so I put it aside for a while and forgot about it.  Some months later when tinkering with horusdemodlib’s RTTY support, Mark Jessop asked me – why not use Horus 4FSK?  I didn’t think I had any hardware that could transmit it.  It was at this point that I learned that RS41ng had been ported to DFM17 and merged in late 2023.  I fired up my ST-Link programmer and was up and running in 30 minutes!  I knew immediately that I had to fly it.  So I did.  It barely cost me a thing, with a fully assembled and powered DFM17 sonde weighing in at 69 grams.  It performed admirably on the flight.

I also enabled the CATS protocol for fun with a beacon once every 20 4FSK packets, hoping I might find someone in range running a CATS I-gate.  No such luck, and I could not spare an SDR to receive it myself during chase.  Maybe next time?

I removed the sensor stalk (I don’t think RS41ng uses it?) and the one real hardware modification I made was that I trimmed the antenna to be a bit closer to the new 434mhz frequency.  I didn’t measure the actual length; I actually desoldered the antenna, jammed it into my NanoVNA, and cut until the peak frequency was about desired; probably about 1cm shorter.  I tinned the end of the antenna where I had cut to prevent fraying, and re-soldered it to the board.

For batteries, I used RAMWAY CR123A lithium batteries, which appear to be the same as what I find in the DFM17 sondes upon landing. In testing, I found that a new pair of batteries ran for about 6.5 hours in my configuration.  On the actual launch day, it ran for about 7.5 hours.

How did it fly?

Amazingly.  The DFM17 competed with the LoRa PITS tracker for telemetry update frequency; they were both about once per second.

The frequency drifted.  This didn’t cause any problems for me tracking; all my trackers had configured a 10khz bandwidth and the frequency varied about 2500hz throughout the flight.  Probably not ideal but it worked?  I’d consider flying one of these as a primary tracker given my experience with this flight.



Link to Sondehub Grafana data.

Experiment: Meshtastic node

I’ve recently found Meshtastic to be interesting, and have seen a couple of other nerds who fly them up high on a drone to see how many contacts they can make before the drone’s battery dies. I thought “this is silly, put one on a balloon! It’ll bridge Michigan, Illinois, Iowa and Wisconsin in one go!”  My actual expectation was that the Meshtastic channel utilization limitations would quickly become saturated.  In preparing for the flight, I heard a few comments that this had been done before – but I haven’t found any write-ups of the flights, just mentions.

The tracker I flew is a Heltec Wireless Tracker, which is basically a Heltec v3 with a GPS chip on-board.  It has a hefty ceramic GPS antenna too.  I didn’t prep or test this payload much other than spending a fair bit of energy trying to script the node to send me periodic telemetry messages showing channel utilization and keeping log of the node list throughout the flight.  I quickly settled on a Raspberry Pi Zero connected via USB, with 3x Energizer Ultimate Lithium batteries in this holder powering the Pi, and the Pi powering the Heltec.  I found issues with the Heltec over USB-to-serial (the Heltec would reboot 90 seconds after listing the node database), so I ended up communicating with it over BLE from the Pi which was slower but worked better.  I logged data onto the Pi’s SD card with the node database, and sent my ground station node a message every five minutes with some basic information including notably, channel utilization.  The code is here.
I built the payload box out of scraps of styrofoam assembled with hot glue, so it didn’t look good and was probably a bit heavy.  But it worked, at least well enough.

In flight it had a lid, I promise, I just don’t have a photo to prove it…
 
How I mounted the heltec before the box was complete (antenna pointing towards the ground)

How did it fly?

Not bad for a largely untested hack which I hacked together in a week.  Two days before flight I did a battery runtime test and ran the whole unit until it died – the next day the Heltec had reverted to factory settings.  Glad I found that before launch day!  The node config I used is here for reference.

The node kept downlinking me coordinates and altitude until under 18km, at which point it appears that the Heltec entered a reboot loop – every time I received a telemetry message after that the uptime was a small number of seconds.  This could be that the Heltec got overwhelmed with too many contacts, the GPS reached it’s maximum altitude (ublox GPS chips require to be in “flight mode” above 12km; the Heltec’s UC6580 probably has some similar limit?)  It could also be that the battery voltage dropped low enough at this point, and/or the payload was simply too cold.

Did it saturate air time fairness limits imposed in the Meshtastic firmware / by the regulations on the frequency?  It doesn’t appear so, but I’m far from an expert.  The node reported up to 24% “channel utilization” at it’s peak.

Ideas for a next Meshtastic flight:

  • See if it’s possible to log telemetry on-board; is it possible to hack the Meshtastic firmware to let me run some custom code?  It’ll save on power and weight to not have a Pi.
  • Test freeze the payload for a long time.  Maybe even with dry ice to get it really cold (this flight recorded south of -20C).
    • Or do something with more batteries for a higher voltage, a heating element, something to avoid the reboot loops.
  • Log debug messages for later analysis?  This might be an overwhelming amount of data.
  • Downlink a message for every new node we see, and it’s lat/lon. Request lat/lon from ground payloads first, and then send it?
  • Write a tracker application which listens to MQTT and feeds data into Amateur Sondehub.
  • Fly a RAK node? The community consensus seems to be that Heltec nodes are the cheapest, and while I’m glad to see (and you’ll later be glad to see) that it’s a Heltec that flew on this fateful flight, maybe a better tracker is worth it?

My ground station “BLUE” which was in the car with me received a lot of positions from Meshtastic nodes that the “🎈” node hit, but not all of them.  Here’s a list from BLUE, with some rows added for manual reports that I’ve received as well.  If you want to contribute your position, drop me a message and I’ll add you to that spreadsheet.  Here’s the list as a map:


Verdict: this gathered the most community interest, so it’s definitely worth doing again!

Re-flown tracker: EAGLE

This is the first tracker I built, way back in like 2016-2017 which first flew in 2018 and has three flights – and an inconsistent track record:

  • Flight 1: died during descent, presumably due to voltage regulator issues. Replaced regulator after Flight 1.
  • Flight 2: Worked somewhat reliably!  First instance of issues with the bme280, which I actually may have found before flight 4.
  • Flight 3: Worked well other than batteries coming out on landing. Removed Canon A810 camera to keep it simple.

For Flight 4, I added a GoPro Hero+ in the same spot that the Canon camera was in. It’s a very old GoPro that I’ve had for nearly ten years; it records video for ~2 hours on a charge.

I had lots of problems with this tracker leading up to flight which I tracked down to I2C bus problems.  Either the INA219 voltage & current sensor was the culprit, or the bme280 sensor was the fault, or the GPS board was doing something weird on I2C (it wasn’t even in use, as I ended up doing GPS via UART and never used the I2C bus connections). I found a dry soldered pin on the bme280, which caused one if not both of the two failure modes, but the ina219 was also reporting negative current values which led me to believe that I shouldn’t trust it. I simply disconnected the ina219, re-soldered the bme280, disconnected the GPS I2C, stress tested, and called it “good enough”.

How did it fly?

During flight, EAGLE had problems different than it had had before.  Go figure. It looks like the environmental sensors performed fine, but the GPS had issues.  As the flight ascended, the number of GNSS satellites used for the fix decreased to around 3 or 4 around 20km altitude, after which EAGLE started transmitting “NOFIX” telemetry strings, where it continues sending me data over RTTY but instead of a lat/lon/altitude it sends these unparseable strings.  These strings don’t get uploaded to Sondehub Amateur, so they only exist on the receiving modem.  Unfortunately my RTTY modem didn’t do any logging, so while I saw these NOFIX strings on my console while chasing, I have no log of them!

But it’s obvious enough to me on this graph that the GPS had issues:

But the bme280 and lm75 sensors performed great, so we get some good graphs despite gaps up over 20km:

Also interesting is that the frame number continued to increment throughout the flight.  It looks like it reset back to 0 on landing, indicating that the batteries didn’t quite stay still on impact – but it got a GPS fix and transmitted a location shortly thereafter.

Here’s a link to a breakout of all the telemetry strings that the Sondehub database has if you want to fool around with the data yourself.

Data link on Sondehub Grafana.

EAGLE internals from a few days before flight:

Old photo from 2017 with the old Canon camera; this flight had a GoPro there:

The EAGLE has indeed landed.  Probably for the last time.

Re-flown tracker: hatTrick aka KD9PRC-2

This payload has flown once, and flew beautifully save for it’s batteries coming out on landing.  The goal this time was to fly it as-is, the only software change being to use my ham radio callsign in the payload name because I wasn’t quite sure how to configure the tracker software to send it somewhere else as a comment.  I didn’t even update the tracker software to the latest version, as “if it ain’t broke don’t fix it”.

I made one hardware change – after a bunch of battery pack drop testing, I tried out zip ties around the battery pack to hold the batteries in upon impact. This seemed to work really well, and a lot more reusable than soldering batteries together, so I went with it.

How did it fly?

The telemetry was amazing, competing for latency with the DFM17 (KD9PRC-4FSK-1).  However my mention of zip ties was fateful.  Minutes before launch reading my checklist I realized that I had forgotten the zip tie on the battery pack.  I decided to disassemble the payload which was already tied in on the payload line and covered in duct tape, which required cutting it open.  Not the best idea when you’re sunburnt from holding a balloon for 2+ hours after an unexpected launch delay.  When doing this, we must have removed the RaspberryPi camera CSI cable – a very easy thing to do and not notice.  Upon reassembly, I checked that we were still receiving telemetry and we were, so tape’d the payload back up, re-did the string, and we launched minutes later.  Only to then realize that the SSDV feed had ceased.  We took 29 pictures of grass at the launch site – that’s it.

The payload flew great and reported telemetry without fail during the entire flight.  I managed to get a second listener, a little TTGO LoRa board running Dave Akerman’s LoraBluetooth code, to receive some packets too and upload them using a quick hack I wrote a couple weeks before launch.  For a future launch, I’ll leave a tracker like this at home plugged into one of my rooftop antennas so I’m receiving LoRa from multiple locations.  In the haste of a bundle of wires in the car at my feet, I pulled the SMA connector off the rooftop antenna that I was trying to use for this payload and spent about 20 minutes of the chase drive trying to re-connect with duct tape by hand with no tools.  I didn’t end up needing the extra receiver, I really just wanted to see that it worked (and it did! 823 packets when the lora-gateway with it’s very nice antenna received 3441)

Data link on Sondehub Grafana.

Q&A

Q: Does the payload use a parachute?
A: Yes – we want a controlled and rather slow descent, and don’t want the falling payload to be much of a risk of hurting anyone/anything.
This flight used a Spherachute 24″ parachute bought many years ago from Random Engineering for my first HAB flights and with three flights already to it’s record. With 838 grams of payload, estimates a descent rate of about 6.8m/s (15mph) at ground level.
Most fascinating part of a balloon flight is what happens to the parachute upon balloon burst.  The chute does almost nothing!  The atmosphere at 30km altitude is <1% of ground level density, so the payload is almost in free fall.  On this flight it looks like it took about 45 seconds for the payload to reach terminal velocity upon burst, with the maximum speed recorded of 58m/s (over 100mph).  Imagine the chaos!

Q: Meshtastic – why wasn’t the node set to ROUTER mode?
A: Good idea – but router mode disables all local interfaces (serial, bluetooth).  I was recording telemetry locally to a Raspberry Pi over BLE during the flight; in router mode this would not be possible.  If there’s a better mode to use next flight which accomplishes the same prioritization, let me know!

Q: What kind of balloon was used?
A: Hwoyee HY-800, an 800 gram latex weather balloon.  It’s huge; about 1m diameter when inflated for flight.

Q: Why was a heltec was chosen as the Meshtastic node, and not a RAK?
Community member MrBeef sums up my thoughts on the subject quite succinctly:

Heltecs are cheap, and I have used several of them so I figured it would be “good enough.”

Q: How much does this cost?
A: It depends on how much stuff you fly, and how high you try to fly it.  A lighter payload with a less ambitious altitude can use a cheaper & lighter balloon with much less helium and top out at 20km altitude.  This flight cost me about $600 – including the $220 helium mistake, so we can iron that out for the next flight with a more reliable supply.  That doesn’t include the cost of a lot of the payload I flew, which was old & reused stuff, including a well worn but still not worthless old GoPro camera :tear:

Q: What is the story about the cat?
A: That’s a good question which I’ll tell over a beer off the record :)

Finally

Thanks for reading!  Want to get in touch about a future balloon flight?  Get in touch with me here.

 

As an Amazon Associate I earn from qualifying purchases.  Thanks in advance if you end up buying any of these parts for your own project!

Posted in Uncategorized | Tagged , , , , | Comments Off on HAB flight 4 – “I’m back in the USA…”

Solderless programming a DFM17 radiosonde

Posted on September 26, 2023 by Trick

Earlier this year I caught my first three DFM17 radiosondes and shortly thereafter discovered gx1400’s dfm_hamradio project (which I’ve been working on) and the Recessim wiki page covering basics for how to hack the device. I “dead bug” soldered wires to the debug port on the board, connected it up to my ST-Link V2, and voila: I had control to program the device!

My hacking setup on a dedicated laptop to let me control the device via relay and receive signal via radio without having to get my hands messy on a daily basis

As you can see from my photos, soldering wires to these tiny pads is treacherous. Trust me….they won’t stay. The header is for a Cortex Debug connector, which would be well served to just buy and solder an Adafruit Mini SWD header as others have done. But can it be even simpler? What if you wanted to program and fly one of these…easily and quickly?

3d printed clip

I designed a little 3d printed clip you can use to hold a Mini SWD header into place on your DFM17 board. It works!

The clip fits just below the sensor plug; this is the reference point for how to line it up. Fit the SWD header into the box with the notch facing towards the top:

…and then fit a 10-pin IDC 1.27mm plug into it from the top, and clip it around the board. The PLA will bend slightly but hopefully doesn’t break for you.

The Result

I actually did do some soldering for the last step, but this time just to make a cable. I’m sure you can buy an adapter from Cortex Debug to ST-Link (both of which are 10 pin box connectors! With different pinouts!) but I decided to fashion myself a simple adapter of my own. Success:

With this I should be able to wipe and flash a newly caught DFM17 in just minutes of work.

How to print

Grab the STL on printables.com and print away. I’ve been using PLA. PETG might be a good choice since it’s more flexible.

The design is in an OnShape public repository if you want to tinker with the design. It’s far from perfect. As of this writing the clip pictured here and tested has a “v6” label on the side of it but any later version I make there should be an improvement.

Print with any old PLA. Must have supports to hold the clip “teeth” up.

Troubleshooting

Clip broke? Sorry about that. It really is a tight fit. I cracked one when I printed with some cheap crappy silk PLA which is known for being brittle, but my go-to hatchbox PLA has fared fine.

 

If you do have questions or want to chat, I recommend the #Balloonchase channel on SecKC discord where some other hackers (myself included, trickv) can be found.

Good luck!

Posted in Uncategorized | Comments Off on Solderless programming a DFM17 radiosonde

Retrieved my first two radiosondes

Posted on March 4, 2023 by Trick

I have been nerding on weather balloons for years now, and the amazing radiosonde_auto_rx project blew my mind when I first ran across it. Back then it was in it’s infancy with a handful of listeners, many of which were intermittent dabblers like me who couldn’t be bothered to keep their station running 24/7. Fast forward a few years, a country move and a child birth later and I’ve dusted off my auto_rx tracker. A month later and I’m happy to present my first two captured radiosondes!

What is a radiosonde?

I’m glad you asked. Have you looked at a weather forecast lately? Radiosondes are a key part of how weather is modeled to give us these forecasts. Twice daily at hundreds of sites around the world, launched on the same schedule of noon and midnight UTC, a weather balloon is launched which conducts a “sounding” of the atmosphere. It contains at least a GPS receiver, radio transmitter, and temperature/humidity sensor which relay back to the ground station the path that the balloon takes and the conditions it passes through. The wind you feel at ground level is never what is happening above you…if you’ve ever explored maps on sites like windy.com which let you visualize wind speed at different altitudes, you can learn that the atmosphere is full of layers. It’s complicated and ever changing.

How does it come back down?

The balloon lifting the sonde expands as the atmosphere things out. Around 30km altitude (roughly 3x the altitude of a commercial airliner) the balloon reaches it’s breaking point, and pops. The sonde then falls back to earth, slowing down with a parachute to make a soft landing.

Where do they land? Who gets them?

That’s the fun part! They land all over the place, and generally speaking the service which launches them does not expect them back. I’ve read reports that some weather services ask you to post them back and even a meager reward for returning the device, but the devices I’ve found are presumably rather cheap and the sticker on them simply says to recycle or throw it away. My first one I found literally in a dumpster, having landed in a parking lot.

Why?

It’s fun! Finding a balloon is a fun chase. It takes you to a new place every time you go looking for one, which is nerve wracking and exciting. It’s proven to be fun and educational for my 4 year old daughter too. She asks questions, gets excited, and thinks about the earth.

My finds:

Lisle – golf course – January 29th

The first radiosonde I’ve ever spotted at landing. Unfortunately on the far side of a fence in a golf course during winter when the course is closed. I managed to see it – which motivated me all the more! But I’ve given up chasing it. Flight path: https://sondehub.org/22046857

It’s hanging from the far side of that tree…I promise…

February 8th – Glendale Heights

My first find! Radiosondy.info sent me a Signal message letting me know of the landing while I was eating my breakfast and hadn’t pulled up sondehub.org yet that day. At 1pm I took my daughter on a short drive to the landing site at an apartment complex ten minutes from my house. I hadn’t been smart enough to bring my auto_rx receiver so I was flying blind, hoping it would be an easy spot. After a few awkward laps driving around the parking lot I noticed a long string hanging out of a dumpster. Hopped out of the car to have a look, and sure enough, there it was. Still transmitting six hours after landing!  You can view the flight path and sensor data on SondeHub: https://sondehub.org/22051868

February 12th – Naperville

In the evening Radiosondy.info unexpectedly let me know that a sonde had landed at the far end of my 20km notification radius. It was late, but the tracking data provided by another receiver had the landing point pretty accurate and safely landing in a school’s football field. This time I brought my pi auto_rx receiver and an antenna with. As I drove up to the predicted landing site I realized that my USB power supply to the Pi was not powerful enough. Good I had brought a backup! Fired it up and immediately started receiving telemetry data from the sonde on the ground about 100m away. A short walk later and I had easily recovered my second radiosonde! You can view the flight path and sensor data on SondeHub: https://sondehub.org/22051876

So far:

What’s next

Finding more will be fun. One landed just the other day 6k from my house, but I’m out of town so won’t get to go check out the landing site for over a week. Will it be there? Who knows.

The real goal is to do something useful with these sondes – ideally attach them to a new balloon and fly them again. I’m planning to conduct my first USA launch this summer, so if I can get some code loaded on one of them, it can ride share. Just a few hours ago I giddily found this project which I can’t wait to give a try: https://github.com/gx1400/dfm17_hamradio and whatever I can learn from https://wiki.recessim.com/view/DFM-17_Radiosonde.

Posted in Uncategorized | Tagged | Comments Off on Retrieved my first two radiosondes

Introduction to ESPHome

Posted on December 31, 2021 by Trick

I’ve long been a tinkerer of home automation:

notice how they are all in a box, now obsoleted.

Since moving to the US in 2019 and buying my first home, my old X10 modules came out of storage. I quickly realized that a whole world of development has happened in home automation since I used these. I had experience with various environmental sensors, but I wanted lots of them, and cheaply. I ran across the ESP8266 boards and became fascinated by how much you can do for how small a cost.  I bought several and even tinkered with building some using the bare ESP8266 chips which cost just $1 each:

most of my esp boards

 

 

I’m quite comfortable with Prometheus, so I wrote some exporters from scratch and found others writing them too. I used a Grafana dashboard to keep an eye on the sensors. I later dove deep into Home Assistant and found myself pushing sensor data from Prometheus into Home Assistant. Throughout all of this, I kept running across the ESPHome project over the course of 2020 and 2021, but it just didn’t click. What is it again? Is it part of Home Assistant? It just didn’t make sense to me. So here goes…an introduction to ESPHome!

What is ESPHome?

ESPHome is a distribution of software to flash on cheap Espressif ESP8266 and ESP32 chip devices to use them with Home Assistant.

What again?

Let’s say you have some ESP hardware and something you want to do with it, for example you want to read a DHT22 temperature/humidity sensor.  You already use Home Assistant, and you want to make your sensor readings available in Home Assistant using your ESP device.  ESPHome makes that as easy as it can be:

  • Wire up the DHT22 to your ESP board
  • Start the ESPHome dashboard
  • Create a new device config and include the sensor configuration
  • Upload your first firmware via USB serial to the ESP device
  • Add the device to the Home Assistant ESPHome integration by it’s IP or mDNS name.
  • Voila – your DHT22 readings are now in Home Assistant!

Why ESPHome?

One of the reasons to love Home Assistant is that it’s yours: you can run it on your own hardware and your data remains your own. You can use it even if your home internet is down – no cloud required. No subscriptions.

ESPHome is much the same: you can make little IoT-like devices, cheaply, and not have someone’s cloud service stuck in the middle.  Home Assistant controls the devices directly on your home network.  No cloud.  Open source software.  Your data is yours.

Is it part of Home Assistant?

ESPHome is technically separate from Home Assistant, however it is basically written for Home Assistant.  It’s separate enough that has been used with OpenHAB, for example. The documentation in ESPHome does show screenshot snippets from Home Assistant. The company behind Home Assistant is maintaining ESPHome to boot.

If you don’t want to use Home Assistant, you can still use ESPHome – or you can consider other ESP firmware frameworks:

What kinds of things can you do with ESPHome?

You can read so many sensors ranging from air quality, temperature and humidity, light…if the device is simple and can be driven by GPIO pins on a ESP/Arduino/Pi board – including I2C and SPI bus applications, you can probably make it work with ESPHome. The documentation is extensive.

You can also use the ESP device to make things happen using relays, display outputs, and many more.

The list of supported devices is extensive, and every device has an example YAML snippet which you can try.  Furthermore there are a lot of brand-name devices which have ESP chips in them, and a community of examples called ESPHome-Devices gives configurations for how to run them with ESPHome.

ESPHome also provides for “OTA” updates, meaning that after the first install of the software on your ESP device via USB-serial, subsequent configuration changes and software updates are done over WiFi.  No wires.

Who is ESPHome for?

Probably two types of people:

  1. Entry level hackers who want to do some basic hardware hacking, like soldering things to GPIO pins on a device like an ESP8266 board and seeing them work in a nice UI in Home Assistant.  You don’t need to write much code, really just some configuration in YAML.
  2. Experienced hackers (maybe like me) who have gone through piles of Raspberry Pi’s, Arduinos and Espressif devices and are just looking for a good way to manage a bunch of customize-able devices around my house without too much overhead writing and maintaining software.

ESPHome Architecture

Before I used it, I was confused about the ESPHome architecture. Does it have a hub or controller? Do I need to run any centralized software separate from Home Assistant?  Short answer: No! :)

Home Assistant talks directly to individual ESP nodes via their IP address (I recommend using mDNS for simplicity). No “hub” or “controller” node in the middle.  Each individual ESP device hosts an API endpoint specific to Home Assistant. You run the ESPHome Dashboard and CLI tools to build firmware images at the time you want to make changes.

How to get started?

Find something you want to do with a little IoT device: read a sensor value, control a relay, something simple. You can even just program an ESP8266 chip to control it’s LED in Home Assistant, which is a great Hello World-esque example.

Make sure you’ve installed Home Assistant already.

Buy one or more ESP devices that come with a built-in USB-to-serial converter. If nothing else, you can find a pack of WeMos D1 Mini ESP8266 devices on Amazon for pretty cheap; however eBay is cheaper.

Install ESPHome.  What this means can vary depending on how you want to use it; I run the ESPHome Dashboard in a Docker container on a laptop separate from where I run Home Assistant.

Plug in your ESP device. Run the dashboard.  Create the device, which generates the basic device YAML:

esphome:
 name: yourdevice
 platform: ESP8266
 board: esp01_1m
logger:
api:
ota:
 password: "ee6d3cc677a5587c8e2a580b330e856f"
wifi:
 ssid: !secret wifi_ssid
 password: !secret wifi_password

Now add a switch configuration to control the on-board LED:

switch:
 - platform: gpio
   pin:
   # Your GPIO pin number for the LED varies by board.
   # on my WeMos D1 Mini boards it is GPIO2
     number: GPIO2
   name: "LED"

Compile, upload to the device.

Now in Home Assistant, go to Integrations, find the ESPHome integration, and add the device by it’s mDNS name, yourdevice.local:

Once you hit submit, Home Assistant talks to the ESPHome node (your ESP device) and finds what controls and sensors it has, and they become available in Home Assistant like any other object.  The LED switch we just specified will look like:

Flick the switch. If you see a light, you’re winning! If not, check your PIN number and board type and tinker until you get it.

Where to go from here?

Get tinkering!

Posted in Uncategorized | Comments Off on Introduction to ESPHome

IO91 -> EN51…NW6 1UE -> 60137…51N -> 41N…2001:8b0:da4::/48 -> 2601:249:902:50a1::/64 (completing the circuit)

Posted on October 14, 2019 by Trick

“There and Back Again, a hobbit’s tale by Bilbo Baggins and The Lord of the Rings by Frodo Baggins. You finally finished it.” – Sam

“Not quite. There’s room for a little more.” – Frodo

Completing the circuit

We just moved back this year from London to Chicago.  We don’t actually live in Chicago – we’ve settled in a house in Glen Ellyn, a western suburb of Chicago.

It’s now more than 8 years ago that I flew to Shanghai on this crazy adventure around the world.  Apparently I told people I’d be back after just two years.  Here I am so many years later, married, and baby CJ is over a year old!

Well traveled

I never thought I’d be tired of flying…but half a million miles of flying later, I don’t mind staying put from time to time.

While based in:

I think it should go without saying that the Great Circle Mapper has been a good friend of mine along the way. I should really get in touch with the author and show my strange maps.

Our journey while in the UK

We moved in 2015 from Shanghai to London.  That was an adventure.  We moved into a little house in southeast London in a village called Ladywell and lived there for two years before moving to the opposite side of London to West Hampstead for another two years.

I’ll remember it as the place where we had the smallest garden patch I’ll ever call “home” in my life, with our cute little shed for bicycles to live and little grill that we had to give up when we moved again.

We settled into that house pretty quick, hanging photos just about everywhere:

The two places were very different to live in.  London is an incredibly diverse city where you can easily get lost in exploring the culture of a specific area and then go to the next village over and find it a completely different place.  There’s a funny little north-south divide (“You live south of the river? We don’t go there.”) to London that I can’t help but think is just due to what I’m going to call the Beck effect; the effect that London tube maps have on the psyche of the people living there. The Thames river is shown to help aide in navigation, but perhaps a side effect is that the Thames forms a mental barrier for transit users.  It could also have something to do with the fact that many of the overground rail stations like Waterloo, Canon Street and Liverpool Street are terminal stations for huge long networks extending hundreds of miles to the north and the south, almost like the Thames river is some insurmountable depth of water to cross.

We traveled a lot within the UK: Bath, Stonehenge, Cambridge a few times, Bletchley which I can highly recommend, the South Downs, Norfolk, Dublin, Edinburgh, Loch Lomond, Liverpool, Monmouth to visit our friends Joan & Jeremy, the Isle of Wight (so easy to get to on national rail). My map of the UK is dotted with stars all over the place. Yet there’s a lot of space between those stars. Much more left to see.

For being an “old’ city London sure is well lit:

What I’ll miss

I miss the rolling, manicured patchwork fields that are distinctive of the UK. Granted, I only saw these while on a plane coming & going, or while reading the NPAS Redhill twitter feed trying to figure out why there’s a helicopter over my house, but nonetheless, I miss it.

Grocery stores in the UK are smaller than in the US, but the food quality is better – particularly the variety, quality and value of ready-to-eat meals. A godsend for young parents.

Tax is included. In the UK (and China to boot) tax was included in the list price for any item.  £2 for a box of Cadbury chocolates cost you – wait for it – £2 out of your pocket.  In the US it’s annoying listed as $2.49 and will cost you precisely $2.7698235 but don’t worry we’ll round it to the nearest lincoln and charge you a rounding fee as well.

Roundabouts.  Seriously USA, just use them.

Trains & Buses

Living where we did in the UK, a car would have been a frivolous expense. We took public transit everywhere.  If it wasn’t one train it was two; if it wasn’t two trains it was a bus and a train. If it was raining and we got the timing just right, we’d catch a cheeky bus ride up the street from our high street station to our flat which is only three stops away. It was just so damn easy. The Chicagoland transit system pales in comparison.

What I won’t miss

Narrow roads. Cycling in London scared me more than cycling in Shanghai, because the roads are narrow, bumpy, and have hard curbs which leave you no where to go when the lane inevitably ends 2.3 seconds after it just began. I didn’t cycle much in London while I was there, despite it being one of my main desires when I moved there.

2011 to 2019 – what’s different?

So many things. 8 years is a long time.

Politics continue to get better every year.  *facepalm*

Google’s now blocked in China among a whole host of things, creating the largest fragmentation the Internet has ever seen. But few of us “see” it.

We crossed 512k routes in the Internet BGP table and we survived to tell the tale.

SpaceX “took off” and even brought rockets back down to earth.

HTTPS is everywhere. IPv6 is getting real.

Smart phones are commonplace.

What’s the same?

XKCD – going strong.  Teaching us stuff.  Helping us figure out how to use the Internet. Keeping us nerds honest.

What’ll never be the same

Language. My view on language has changed. The English language is shit and requires constant interpretation unless you know the speaker rather enough. Chinese is a whole other complicated beast, but I can’t help but think just how much harder human existence with an imprecise language such as English being so essential.

Units of measure. I talk in centimeters and meters and it weirds people out. Unfortunately the legendary Luban Ruler was confiscated by airport security so most of my tape measures are in inches, and Menards does just about everything in inches anyway.

Food. The world is full of a wild variety of food; enough variety that you’ll never be bored of trying new things if you get out a bit. A friend of mine once told me that Indian curries are so flavourful that he “forgot” to eat meat for several months at a time instead preferring vegetarian curries. Another friend told me that food without spice cannot be enjoyed; I didn’t get what he meant at the time, but now I understand.

Picked up along the way

I learned about ham radio, as a result of developing an obsession with high-altitude ballooning.  I ended up getting my “Advanced” license in the UK, which is the highest qualification of license you can get. So far I haven’t found a route for me to get a corresponding US license for free, so I’m probably going to have to take the exams here all over again. C’est la vie.

Celsius. I learned to talk weather temperatures in Celsius.  It wasn’t hard really, you just have to try.  I switched my locale on my mobile phone to show me things in Celsius.  I wish more apps showed both because unfortunately I now live back in a place where Fahrenheit is the norm and Celsius is treated like communism.

Eddie Izzard. We saw Eddie so many times, I think four times in London. We saw him this summer while he was in Chicago too.  He’s still keeping us laughing, but also trying to tell some real stories about his life and maybe change a few things in politics too.

Andrews & Arnold ISP. I can’t say enough other than that they might just be the best damn small ISP in the world. Is your ISP on IRC available to answer you questions? Do they give you bandwidth and latency graphs for your connection to help you diagnose usage of your line? Do they promise to never censor you? So far, A&A is the only ISP I’ve ever met with this level of service. Simply impeccable.

So what about all those numbers in the title?

If you know me, you know I like numbers.

IO91 -> EN51: IARU locators, which are used in amateur radio to divide the world’s land up into evenly-sized panels.

NW6 1UE -> 60137… postcodes

51N -> 41N: GPS latitudes

2001:8b0:da4::/48 -> 2601:249:902:50a1::/64: yup, my IPv6 block that I had with AAISP in London, and my IPv6 block from Xfinity. Nerd.

Adjusting back to life in the USA?

I get asked this a lot. In short, it’s weird, on a daily basis. I think I’ll be settled by 2021.

As a form of protest, I continue to drive on the left.  Maybe it’ll catch on.

Posted in Uncategorized | Comments Off on IO91 -> EN51…NW6 1UE -> 60137…51N -> 41N…2001:8b0:da4::/48 -> 2601:249:902:50a1::/64 (completing the circuit)

HAB flight 3: two payloads, some success, and more failure

Posted on April 23, 2019 by Trick

This post is a bit late given the launch was two months ago, but hey, I’ve been busy. We had a baby last year, and I’m moving to the US this month.

Launch day, site, people

We launched on Sunday February 24th from Steve Randall’s site in Elsworth, UK.  Steve (obviously) came out to meet us, and supplied the balloon and helium (and in the end the parachute too).

Helping me out on launch day was Marcus Daniels (driver) and Noel Vasquez (comedy).

Payloads

  1. Trusty old tracker “EAGLE” through it’s third flight.  Only real modification is that I removed the Canon A810 camera given that it doesn’t produce very good photos, which saves weight (~170g) for other payloads. 315 grams. RTTY signal at 50 baud 8-N-2.
  2. New tracker named “hatTrick” given it’s my third flight. It’s a Pi Zero build of Dave Akerman’s “DIY Lightweight Pi Tracker” built pretty much to the letter but with my own cheap case made of an old ice cream styrofoam box. I used 3xAA batteries with no voltage regulator. 94 grams with the box! Not bad. LoRa mode 1 signal w/ SSDV.
  3. “hiadsb” – a revisit of my last flight’s “see how far away I can receive ADS-B signals” experiment. I used a different battery pack this time, and added a cantenna ground plane to the el-cheapo nooelec ADS-B antenna. 179 grams.
  4. Steve Randall’s X2 tracker + a GSM backup tracker which he wanted to try.

Balloon & such:

  • Balloon: 1200G of a new brand that Steve wanted to try (I didn’t get the name.)
  • Parachute: 36″ PML Durachute
  • Neck lift: 2.4kg

See my weight tracking sheet for reference if you’re curious how I plan for this leading up to a launch.

Launch planning challenges

February in SE England isn’t a great time to launch.  Winds shift regularly and often blow quite strongly sending any payload into the sea. At one point a few days leading up to the launch, we were convinced the launch would have to be postponed given the following options for a Saturday or Sunday launch:

hourly predictor on 2019-02-18

My original idea was to use an 800g balloon for a slightly shorter launch staying a bit further inland.  However the night before the launch the predictions shifted again, and put a 800g balloon landing exactly on Runway 22 of Stansted airport.  Bad idea!  If we launched a bit earlier, instead of Stansted we’d land in Braintree. Bad idea again. 12 hours later (a mere 4 hours before launch), the predictions shifted yet again and gave us an opening. Steve suggested to use a big balloon (1200g) to keep the payload afloat a lot longer and put it down south of Colchester.

Chase

The chase was fun because as you can see from the photos, it was a beautiful day. We watched the balloon ascend to a few thousand meters.

At some point we lost track of the balloon visually. Why?  Because we didn’t look at our prediction nor the azimuth on the tracker UI.  At 3800m the balloon hit a different layer of atmosphere and did an abrupt U-turn:

I sat in the passenger seat and gave directions to Marcus, whilst also tracking my balloon on both LoRa (using a Pi via network cable with a LoRa radio on it) and RTTY (via a SDR in my laptop). Tracking both simultaneously wasn’t as hard as I’d thought, but I did have trouble keeping two antennas mounted on the roof. In the end I just used one antenna and switched back and forth between the two trackers but I had plenty of listeners. Sadly I hadn’t announced Steve’s X2 tracker so not many people knew to tune in.

I also plugged a USB GPS receiver into my laptop to provide dl-fldigi with a GPS location source so I could show my position on the tracker website in real-time as I received data. This worked well until the GPS receiver died. It’s since been declared dead. It was a cheap enclosure of a uBlox 7 chip.

Burst

New altitude record for me: 34,000 meters!  We were aiming for 32km.  Every meter up we went was another meter closer to a wet landing, so when we started to rise above 32km I started to sweat more.  But we hit a nice high altitude and stayed dry.  PHEW.

Recovery

Lucky me. We landed 20m from a road, in a field, plain sight.  Double lucky, I think the payload train missed a tree near the landing site probably by a few meters.

Good thing, because not only did I have one tracker failure on landing, but two!

Steve drove faster than we did and was waiting for us at the landing site.

We landed about 3500m from the water.

What worked & what didn’t

Success: SSDV

I can’t take any tech credit for this as it’s all Dave and the PITS software which runs on it. But it worked and sent back some great photos which was fun for family to watch as the flight went on.

Double-fail: Battery packs on landing

I’ve read over and over about people soldering batteries, which sounded like over-engineering. Until this time!

Epic fail: hiadsb ADSB experiment

This payload died entirely and presumably in spectacular fashion.  The Pi Zero that it ran on is dead – fried. The SD card is fried too – nothing will read it anymore. My suspicion? The cheap battery pack that I flew (which I’ve never tried frozen) must have a bad voltage regulator in it and it fried the Pi. Unfortunately this led to zero data coming back. Sad.

Fail: BME280 sensor on EAGLE

It failed on the last flight, why would I expect it to work this time without me fixing it?

Other things I learned

  • Payload prep is something I should do more of at home. Have the payloads with good fresh batteries ready to go, and have a way to quickly seal them up to launch quicker. We arrived at the launch site around 10:20 and didn’t launch until about 11:45 which, on a day where the winds were against us, meant a very different landing site.
  • Bring lunch. Stopping for lunch wastes valuable time. One day I’d like to see a payload land, but you’ve gotta drive efficiently to get there.
  • Mag mount antennas need testing at high speeds.
  • PITS low resolution photos on the ground mean low resolution photos on disk. Which means you get crap resolution photos of liftoff. While this is good for SSDV not great for post analysis. I might look into fixing this or next time send full size photos on the ground.
  • PITS only takes photos by default once per minute. I never thought much of this, but it’s not very often.

Photos & video

OK, here’s what you came here for:

Post launch battery rundown

After bringing the payloads home and making copies of the data, I put the used batteries back in and ran each of the trackers to exhaustion to get an idea of how much battery life was left in them.  They were powered on for about 4 hours, and each had plenty left to spare: EAGLE 16 hours, hatTrick 10 hours.

Radio listener analysis

Finally I win! All I had to do was track my own balloon.

Further analysis

Still need to figure out what happened with the BME280 sensor. That’s weird.

I would like to spend more time analyzing the ascent and descent velocities, especially somehow visualizing them vs. altitude.

I don’t know how to get a link to the telemetry data on habhub.org now that the launch is a bit old. It’s like my data has been archived even though this was a “live” flight.

My photos from EAGLE have the wrong telemetry data on them. Looking at it now two months later, I think I’ve substituted data from my launch in May 2018! That would explain it. Unfortunately I’m tired and don’t have easy access to my HAB data archives at the moment, so this’ll have to wait for another day/month/never.

What’s next?

  • Fix some things
  • Maybe a first US launch when I arrive back there?
  • Maybe another similar launch in the UK in June when I visit
Posted in Uncategorized | Comments Off on HAB flight 3: two payloads, some success, and more failure

HAB flight 2 “EAGLE”

Posted on May 22, 2018 by Trick

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.”

Posted in Uncategorized | 2 Comments

First high-altitude balloon flight: lots learned

Posted on February 18, 2018 by Trick

What is High Altitude Ballooning (HAB)?

Build a computer with a GPS receiver and a radio transmitter, attach it to a big balloon full of helium, and let go.  It rises up into the atmosphere, and as the air gets thinner, the balloon expands and eventually bursts.  The computer is continuously sending radio signals down to tell you it’s GPS position.  You then drive to the estimated landing area and find the computer.  Why?  Put a sensor on board, such as a camera, and you can see what Earth looks like at an altitude well above what you’ll ever see out an airplane window.

The UKHAS website has more information: https://ukhas.org.uk/

How I got here

I’ve been preparing and building my first tracker since coming home from the UKHAS conference in 2016.  It has taken me a while to build it – I ordered the radio transmitter and RTL-SDR receiver in the fall of 2016, built and sent my first RTTY packets and learned what it means to “bit bang” a signal. I prototyped on an Arduino but quickly moved to a Raspberry Pi since I’m a Linux nerd.  I tracked a handful of balloons in 2017, and in the fall started to get serious and actually drew a “design” :)  In November, I decided I was ready.  I wasn’t, but I started looking at launch sites and asking the UKHAS community for help with my first launch – the community really is quite active and willing to help – a happy distinction from some of the IT communities that I frequent in my day job.  IRC is always busy.

Launch date bingo

After deciding my tracker was ready in November and Dave Akerman kindly agreed to host me for a launch at his site in Ross-on-Wye.  Sorting out a launch date takes time.  Weather is the top challenge: you need to have decent ground weather (e.g. not too windy, lots of precipitation makes it miserable and can also make chasing & retrieving challenging, I hear.)  You then need to think about the ever-changing weather up in the atmosphere – these winds, combined with the trajectory of the balloon up & down, give you a predicted landing spot.  We use the CUSF landing predictor to run simulations.  On top of this, you have to have approval from the CAA for the launch site, and a NOTAM issued so that air traffic control and pilots know you’ll be in their airspace.  Dave has prior approval for the launch site, so only needs to deal with the NOTAM which needs to be issued a few days in advance.

You also need to hire (“rent” in the US) a cylinder of helium, which you can keep for 3 months.  I hired mine mid-December from click4balloons.co.uk.

Dave and I traded emails throughout November but we were both travelling.  We penciled in a date in December, but had to scratch it for weather (and I was ill enough that I’m glad we didn’t launch, hindsight.)  We picked a date in January and had to scratch for weather again – wind was going to blow the balloon almost down to Gatwick airport.

We settled on February 11th with a launch prediction landing near Banbury.  Dave filed the NOTAM; you can see active NOTAMs on various unofficial sites like notaminfo.com.  Here’s mine:

selection_259

Payload specs & balloon

Balloon: Hwoyee HY-500
Parachute: Spherachute 24″
Payload box & line purchased from Random Solutions.  Dave on launch day decided that my line wasn’t strong enough for a windy day and used some of his – something I need to ask him about / what specs he looks at with payload train lines.

Payload:

  • Raspberry Pi Nano W (the original was a plan Nano, but I fried it.)
  • Pi Camera v2, pointing up towards the balloon
  • uBlox MAX-M8Q from Uputronics, lines soldered in
  • Micro USB to TTL serial converter for GPS I/O
  • Radiometrix MTX2 dangling with soldered leads, TX pin to Pi UART, EN pin to a GPIO
  • UBEC DC 5V power regulator**
  • 4x AA Energizer L91 Lithium batteries
  • BME280 temperature / pressure / humidity sensor, outside the box
  • LM75 temperature sensor, inside the box
  • Canon A810 point-and-shoot camera running CHDK and a slightly modified version of the script here which takes a photo every 10 seconds.  I bought the A810 on Ebay for £13 as it had a broken screen which is perfect for this job, as I turn the LCD off anyway.

Total weight: 550 grams, including the parachute and line.  Dave’s BUZZ tracker added a whopping 37 grams.

I wrote my own tracker software.  I could probably use the PITS software with little  modifications, but I wanted to learn it.  I’ve published my software, BSD licensed, on GitHub as “radio flyer”.  It’s written in Python 3 and might be useful to someone else, if nothing else, it’s interesting.  Please borrow / fork / ask questions.

** UBEC: I’m pretty sure I shouldn’t be using this :) It’s meant for LiPo batteries…and might have been part of the failure during descent.

Launch day weather: uncooperative winds turn into another experiment

Leading up to it the prediction looked OK, but on Saturday it became apparent that the ground winds were dangerous.  Consistent winds of 15+mph and gusts of 30’s.  I’d already rented a car for the day for Sarah and I to drive out there, so I figured we’d make the drive out anyway, even if we had to scrub the launch.

We sat in Dave’s house drinking tea and getting to know each other a bit.  The wind didn’t let up, however we started to float around a crazy idea.  The launch field is on a hill, and the hill slopes down westward.  At the bottom of the hill is a line of trees.  Wind in itself isn’t a huge problem, indeed as the launch photos will show, it’s even more windy the further up you go – however wind on the ground is trouble.  The balloon needs to clear obstacles on the ground; namely, the power lines going over Dave’s house at the east end of the field.  The trees blocked the wind for the first 15 meters or so of altitude, so we could prep the balloon there, wait for a brief gap in the wind, and let it go.  We did some quick mental math to make sure the balloon’s ascent velocity would carry it high enough quickly enough to clear the power lines – and indeed we turned out to be right.

Not that it wasn’t nerve wracking, but we went ahead with it!

Launch

img_1605 img_1585 img_6437

img_6444

Up, up and away!  It cleared the power lines just fine, as we’d estimated.  The wind was worrying at times – I wouldn’t recommend a windy launch.  There were a few gusts where the balloon carried to the side and without enough clearance it might be easy to puncture the balloon.

Chase drive

Something I never expected to work: I put my home-made yagi antenna in the back seat of the car, horizontal to the ground, and sat in the front passenger’s seat with my laptop + SDR receiver.  Since the balloon was above us at a decent angle for much of the chase drive, I was able to receive radio signal.  I had decent reception throughout the flight all the way to maximum altitude.  I’m getting a better feel for radio waves, I guess.  I thought a directional antenna like a yagi would almost “filter out” this sort of radio…

Burst

I had estimated the burst to be around 29km when shooting for a 5m/s ascent.  Due to the high winds, we added extra helium to shoot for a 6m/s ascent rate – which would bring the burst altitude down, I figured to more like 28km.  The balloon went further – the max altitude I recorded on the SD card was 31005m.  Crazy!  The upwards-facing photos around the time of burst show the balloon to appear shiny which is quite cool.

img_6895 Zoom in on the right-hand side photo and you can see shredded bits of the balloon.

Descent velocity

Something I hadn’t spent enough time thinking about – is that the atmosphere at the time of burst is so thin that the parachute does very little and the payload descends quite quickly.  Telemetry data confirms it for this and every other flight.  Looking at the GPS data on the SD card which is recorded at 1Hz, the maximum descent velocity is 53.9m/s which is 120mph!

During the descent, the payload gets quite cold, and sure enough, my tracker died.

Landing & recovery

We made good time driving despite a few navigational errors – I was spending too much time looking at telemetry data and not enough on the road ahead.  Dave parked at a spot near Lower Compton and we watched the telemetry data on habhub, as well as read the incoming signal on his handheld receiver.  We made such good time that we were parked about 2km away from the landing spot, at Butler Hill Farm, while the balloon was at ~1.5km altitude.  We tried but didn’t manage to catch visual of the payload descending.

Recovery was straightforward.  The GPS marker showed the payload about 500m north of a small muddy drive (which turned out to be a private drive), in the middle of several fields.  As we drove we were able to spot the payload rather easily.

img_1631

 

img_7175

SAM tracker failure & analysis

The worst part about me having radio reception in the car was realizing the moment when my tracker failed.  Suddenly the beautiful two yellow bars of RTTY signal in dl-fldigi fell silent.  Other receivers on IRC confirmed that the radio signal had fallen silent.  Not even a single tone which would indicate that the tracker software had crashed – the transmitter fell entirely silent for the rest of the flight.  Thank goodness for BUZZ, else it would be nearly impossible to find the payload.  The last transmission received from SAM was sentence 553, showing 15318m.  However as astute trackers may have noticed at the time, SAM has a large output buffer on it’s radio transmitter – on the SD card, I had two more sensor readings; a further 50 seconds of data.

My initial impression looking at photos from the Canon A810 camera were that the payload went through a cloud of snow/ice on it’s way down.  If the payload was moving quickly, maybe a lot of moisture went inside the box, causing a short?  However later correlation of photo times shows that this cloud was at 2km altitude, much later than when the tracker failed.

Looking at the temperature data on the descent, as expected, the payload got very cold.

Temperature readings at burst: external -20C, internal -18C
Temperature readings at tracker failure: external -44C, internal -30C

The views at the time of tracker failure:

img_6941

I really wish I’d had a voltage sensor on-board.  I suspect that the 4x AA batteries at this temperature put out just low enough a voltage to cause the Pi to hang.   In testing I found that the Pi would crash when voltage was down around 4.5V, which isn’t much of a margin when the theoretical voltage from the battery pack is 6V (stepped down to 5V by the UBEC regulator.)  It could also be that the UBEC is unsteady with lower input voltages; Steve Randall mentioned that the UBEC I’m using is meant for higher input voltages than what I’m using in the first place.

Followup before the next flight:

Habitat reporting position in Bermuda?

One other oddity which I need to test out again is what to do when I’m transmitting sentences where the GPS has no fix.  I had a special case in my tracker code which sent a sentence like this:

$$SAM,47,NOFIX,13:42:04,4,6.99,989.28,50.96,868,20.875*3399

I didn’t include any latitude/longitude in the sentence, thinking there’s no point in sending zeroes. But perhaps habitat interprets this in a weird way when there is no latitude/longitude interpreted at all?  Needs more testing.

Unfortunately now a week after my flight, even though habitat has my data stored, I can’t find the data on the tracker mobile site anymore.  Let me know if you can find it.

Telemetry & Sensor Data

I’ve done up a bunch of charts of sensor data in Google Sheets.

Here’s a photo of tracker.habhub.org showing BUZZ’s flight path:

selection_260

Photos

Conclusion

Other than the extensive list of todo items I keep adding to this week, only question remains: when’s the next launch?  :)

Posted in Uncategorized | Tagged , , , | Comments Off on First high-altitude balloon flight: lots learned

My first radio contact from a high altitude balloon

Posted on October 10, 2016 by Trick

I’ve been watching – with awe – the number of high altitude balloon (HAB) launches there are here in the UK, and thinking about building my own and sending it up.  Last month I went up to Cambridge for the annual UKHAS Conference which was really interesting. Not only are people launching balloons to great heights above 30 kilometers, but there are also solar-powered trackers on “floater” balloons which rise to a certain altitude and circumnavigate the earth many times (see UBSEDS18 for an example).

I want to build one, but figured the first step was tracking.  I picked up a cheap SDR module, and set off building a yagi antenna.  I finished it back in August, but after the conference, I was determined to find a launch in the UK that I could try and track.

I finally got my chance on September 24th with a balloon launched in Wiltshire called “Stabilotron-II”.  The launch was a slow ascent of 1 meter / second which is slower than a lot of flights, so I had plenty of time to set up.  It worked!

$$STABILOTRON-II,532,11:56:54,52.7128,0.1321,16259.040,46.130,16,186,-7,3.227,31.93,31.93,27.50*4D4E

This is the first clean data sentence I received.  At 50 bits / second.  Over radio waves.  Pretty cool!

Here you can see my homemade yagi mounted on a camera tripod, sticking out the skylight window of my top floor bathroom.  I tracked the balloon with varying success from the midlands over Norwich and across the sea until it was over land in the Netherlands.  The quality of my antenna & receiver setup isn’t that great – during the flight I had to make a lot of adjustments (including moving my laptop away from the antenna – makes a big difference!).  My last recorded contact was at a range of about 300km somewhere over/past Rotterdam – which is pretty amazing!  After that, I could receive some data, but only in patches; not enough to get clean tracking data back.

From the HAB tracking server statistics, I received 221 “sentences” which isn’t much compared to most of the other receivers, but not bad for only £30 in parts.

For software, I used:

  • dl-fldigi v3.1 on OSX
  • HDSDR bundle for OSX which includes rtl_tcp (my USB SDR is a RTL2832 + R820T2)
  • Soundflower for audio routing from HDSDR to dl-fldigi

I’m fussing with a raspberry pi to build a dedicated tracking machine for future flights which I’ll surely get done one of these days.

The experienced trackers are clearly a lot better at this – but hey, I parsed 221 messages, which ain’t bad for a first go :)

Next step: actually assembling my own HAB payload and launching it!

Posted in Uncategorized | Tagged , | 1 Comment

Iceland – Aurora Borealis

Posted on September 1, 2016 by Trick

These photos are best viewed while listening to Island Songs (Ólafur Arnalds).

Last night we saw a spectacular show of the aurora borealis.  There aren’t any words to quite describe it.  We saw the first glimpses around 9 PM (Iceland time) while the sky was still lit from dusk, and at first I thought my eyes were playing tricks (pun intended) on me.  The show started slowly and faintly at first but didn’t waste any time.  It was quite brilliant for the first few hours and generally came in ribbons which spanned maybe 20 degrees of the sky.  The show only let up lightly – there was always a faint haze in the sky from it.  Later past midnight the show was less intense but more spread throughout the sky.  I stayed up until everyone had gone to sleep and around 2:30 AM I noticed my lens was fogging up – the temp had dropped to a cool 3°C, the camera was cold all over and I couldn’t keep the water from condensing for more than a minute at a time.  I called it a night around 3 AM.

Normally I try to pick out a favorite shot, but in my roll of 200+ shots, there’s really about 50 truly amazing photos in there.

One of the best aurora photos is this one:

My favorite shot of a rather large bunch of really truly amazing shots is a 10-minute exposure star trail + blurred aurora:

For the photos: Sit down, put on the song Particles, and browse the full image set.

I also took a few series of timed shots which I then animated and put on YouTube:

Many thanks go to the Aurora Service website, to Jake Ruston for his Aurora app, and to the Icelandic Met Office for their satellite imagery as Weather Underground’s syndicated satellite feed doesn’t go this far north.


For the photography nerds out there…read on.

Photos taken on my Canon T5i (700D) w/ EF-S 18-55mm f/3.5-5.6 ISM lens between 10 PM on August 31st, 2016.  Most shots are fully zoomed out at 18mm, f/3.5, with exposure lengths from 4″ to 10″ and ISO set to auto varying all the way from 160 for longer 30″ exposures to ISO 3200 for some of the shorter shots.  I can’t decide which shots look better, the 30″ ISO 200 shots or the 6″ ISO 3200 shots that have so much detail but a bit of grain in them.
Photo stitching is done with mencoder and then uploaded to youtube as a 4k video.
Photo series are timed and exposure controlled with a TriggerTrap.
Since I’m traveling and using a small suit case, I only had my GorillaPod tripod with me.  A lot of shots show a small amount of false “star trail” which is artificial – it’s the camera moving slightly and slowly during the longer exposures.

All in all shooting this with my camera wasn’t really that hard.  Just put the camera on shutter priority mode, set it to a few seconds, and set it to a 2-second delay before taking the shot so you can let go of the camera before the shutter opens.  Hardest part was getting the focus right.  The only way I could get it right was to find one of the pesky neighbor houses a few miles away with a bright lamp on their porch, zoom and focus on it, and then zoom back out making sure I leave it on manual focus. Then just never touch it.  I wish the camera/lens had a firm way to zoom to infinity, but the lens lets you zoom beyond infinity which produces reliably blurry images.

To really shoot this…a full frame camera wouldn’t hurt at all.  A fixed wide angle lens would be perfect for this, and a more sturdy tripod.  I’ll probably buy a wide angle lens for just-in-case someday I find myself here again :)

Finally, for Sarah:

 

Posted in Uncategorized | Tagged , , , , | 3 Comments