Sometime last year I came across a Python library for controlling a GoPro camera, and was interested because this provides a means for a Raspberry Pi to capture photographs from a GoPro during a HAB flight, and then send those images to the ground via SSDV. I happened to have some GoPro cameras one of which has the necessary WiFi ability. It didn’t take long to have a script running that would take images and transfer to a Pi, and I then integrated this into my Pi In The Sky software. I even wrote a blog post about it, but held off publishing till I had a chance to test it in flight.
A week ago I noticed that predictions for this week looked good, with Wednesday having a good combination of nearby landing and low launch winds. So on Friday I quickly put an application for Wednesday morning (I need to give the CAA 72 hours notice so Monday would technically have been too late). I spent Tuesday preparing the payloads, receivers and the chase car, but when Wednesday morning came the launch winds were a bit high for a solo launch. Since I had 3 payloads to launch (camera, backup radio tracker, GSM tracker) and needed to use a large balloon to avoid landing in the Severn or the Forest of Dean, I decided it was best to wait for another day.
When I checked the predictions, I saw that predictions for the following morning were much better – half the launch winds, and I could use a small balloon to land safely. I quickly sent an email to the CAA asking for the NOTAM to be changed or reissued, if possible. Obviously this was within my 72 hour notice period, but that’s in place to stop people asking on a Sunday for a launch on Monday. Also, my NOTAMS are generally issued within a couple of hours or so, so I felt positive that the CAA would respond positively, which thankfully they did.
This was delayed for about an hour due to a couple of issues with my GoPro tracker. First, it couldn’t get a GPS lock. Often this kind of issue is to do with having a camera nearby, but this time it was actually a faulty GPS antenna; it looked fine – no breaks in the wire and the SMA plug was intact with no breaks or shorts – but it just didn’t work. Swiftly replaced with a spare.
Second problem was that the GoPro was showing a low battery. This was very odd, as I’d left it charging for a few hours the previous day and hadn’t used it since (but more on that later …). So I connected to a charger, added a powerbank to the payload to keep the camera charged in flight, and delayed the flight for an hour to allow the camera to partially charge.
The delay did mean that the flight would land a little further East, which gave me more margin in case the balloon burst late. I ran various prediction scenarios and was satisfied that even a very late burst would be fine. So with all trackers powered, transmitting and being decoded, I enlisted help from a neighbour, filled and launched the balloon.
With a flight time of well over 2 hours, there was no rush in chasing. I checked that all the receivers were running OK, enabled the packet-resend uplink (which requests that the payload re-sends any missing image packets), and then set off in the chase car.
The prediction was for a landing near Yate, so I took the M5 south, stopping at the Gloucester Services to check the live map which, unfortunately, was running with a huge time lag as the database is still full of radiosonde data (it’s being cleared, but not soon enough for my flight). Normally I wouldn’t be concerned, as my car has an Android head-unit with its own mapping, but a recent change to that and/or something specific with the tracker configuration meant that the app kept crashing.
Another problem was that the SSDV from the GoPro stopped at around 16km altitude. I wondered if the battery had discharged (though it shouldn’t have, as there was a power-bank connected also), but again more on that later. Anyway, the images so far were pretty good.
From the M5 I took the M4 east, and made the mistake of using the online map which showed an expected landing south of the M4. So I turned right towards Bath, and parked up to check more carefully. With my head unit app unusable, I connected my phone to a USB OTG receiver, and used my phone app to show the balloon, car and predicted landing spot. This worked great, and I saw that the landing prediction was north of the M4 (as I’d expected earlier), so I turned round and aimed for the prediction.
The closest road to the landing prediction had fields either side, with several places to park off the road. It was on a hill so initially I drove to the top, hoping to get a signal from there till the flight landed, but after a while the landing prediction moved to be quite close to the road itself. So I drove back down the hill and parked under the expected flight path. I moved from the a couple of times as the balloon, and prediction, meandered.
Initially the flight was tricky to see, coming out of the sun, but once it was north of me I saw it easily.
And I even managed to photograph it as it landed – you can see one white payload box (GSM tracker) about to hit the ground, and another (white with pink tape and containing the GoPro) stuck in a tree to the right.
Coincidentally, the farmer was driving around the field. I beckoned him over, explained about the parachute in his field, and he said to jump over the gate and go get it.
On the way I passed a calf having a long afternoon nap. That was the reason the farmer was there – to find out where the calf was hiding!
So, That GoPro ….
When I got the payloads back to the car, I checked the GoPro and it was still powered up, so power wasn’t why it stopped taking photos. It was very very warm, as was the tracker (a Pi 3 A+), so maybe that was it. Anyway I left both running so I could check them when I got home.
Back home I hooked both the Pi and camera up to mains USB power adapters, connected the Pi to my LAN via USB-LAN adapter, and connected via ssh. The camera script had stopped. I ran the script again and it failed with a library error during the “take photo” function. Odd. I let the camera cool down and tried again, but same error.
So I took the SD card out to copy the contents, and noticed that the card was full. That was odd as I’d cleared it of all files the day before, when I charged the camera. So I checked the files, and the majority of the card capacity was taken up with video files. I opened them, and all just showed ….. video of my USB charger! So, the reason the card was full, and the reason the GoPro battery was nearly discharged before flight, was that I’d accidentally touched the record button when I connected the camera to the charger. Ooops!
So that’s something to be careful of next time, and a reminder to check the SD card capacity when the payload is prepared on flight day, not just before.