I’ve flown a few different types of camera on my HAB flights, starting with Canon compact cameras in my early flights, and Raspberry Pi cameras in many of my more recent flights. GoPro and other “action” cameras are popular, and I’ve flown them a few times, though their rather extreme lens distortion does encourage comments such as “it’s so curved it must be flat” from the flat-earth contingent of the lunatic fringe.

Most of the best photographs on my flights were taken by the Canon compacts, so I wondered about what improvement there might be from using a better camera. SLRs are too heavy really, and I wouldn’t want to risk damaging something that expensive or delicate, so my attention turned to “mirrorless” cameras which use large sensors and interchangeable lenses but are smaller, lighter and less delicate than SLRs.


Image result for eos m 22mm

Canon’s first such camera was the EOS M, and I bought one soon after it came out based on its compatibility (via an included adapter) with my Canon SLR lenses. It came with a 22mm “pancake” lens and I soon added a couple of zoom lenses to the kit. Image quality was very good indeed, but focussing was rather suspect. Canon knew this and brought out improved firmware but it still focussed much more slowly, if at all, on difficult subjects. And by “difficult” I mean anything that isn’t sharp and stationary.

A couple of years ago I bought an an EOS M100, which has much improved focussing and is a camera I now use a lot. The EOS M remained unused, as did (pretty much) that 22mm lens, so I had a camera with very good image quality that I wouldn’t be too distressed about if lost or damaged in a balloon flight …


With battery life measured in 100’s of shots rather than 1000’s needed for a balloon flight, I needed to arrange an external power supply for the camera. Canon sell a suitable device, and clones are available, where a USB connection is boosted to battery voltage and then fed to the camera through a dummy battery. So I bought one of those, plus an Anker PowerBank with 2A capacity (to handle peaks) and tested it continuously for several hours to ensure that it would comfortably last through a typical 2-3 hour flight.

Magic Lantern

I needed some way of having the camera take images thoughout the flight. With the Canon compact cameras I used “CHDK” firmware, and the equivalent for Canon SLRs and M-series cameras is called “Magic Lantern”. It’s very easily installed, and very easily configured to take a photograph every few seconds.

Image result for magic lantern intervalometer

I configured the camera to store photos as RAW files as well as JPG format (though somehow I managed to switch that off before the flight, or the intervalometer ignored the setting), and set the camera to manual focus (to include infinity) so it wouldn’t need to try (and probably fail) to focus on fluffy clouds.

Payload Design

I wanted to soften the landing to help prevent damage to the camera, so I built an internal sub-frame for the camera, with soft foam suspension underneath to reduce the forces on the camera. I included a slight tilt to the camera so that it is generally looking downwards, though the natural swinging of the payload results in many viewing angles through the flight anyway.

Flight Plan

With predictions looking good for Saturday, including low launch winds, I applied for permission. I was originally hoping to do another flight with inter-balloon telemetry to a balloon in Northern Ireland, but there wasn’t time to get permission for that flight (the launcher doesn’t have permanent permission for his site, so it’s a longer process). That left me with permission for a launch, so I looked through my other planned flights to see what might be best to launch. Cloud cover was looking good (i.e. a lot less than 100%) so I settled on this photographic flight.


I also wanted to test some radio trackers. Testing isn’t a great idea if you want to actually get the flight back, so I included 3 trackers in case one failed. First was a simple and very reliable AVR tracker which I’d programmed to send regular LORA transmissions plus Calling Mode transmissions. Second was a Pi Zero tracker switching between LORA and RTTY (both via the same LORA module). Third was a GSM tracker. All 3 had flown successfully before though the radio trackers hadn’t used those radio settings.


The conditions were very pleasant, as expected, however 2 of the trackers decided to be awkward. First the Pi Zero couldn’t get a lock, and I had to rehouse it in a larger payload container to keep the GPS antenna away from the power supply. Secondly, the GSM tracker failed to send any positions. I flew it anyway, in case it was a local issue, but it didn’t send any positions when it landed either. Investigation after the flight revealed that the GPS antenna cable had broken internally (and invisibly).


With the landing area not far away there was no need to rush, so we left when the balloon was about 1/3rd of the way up. The flight path was typical for a summer launch, with the higher altitude winds bringing it west, against the lower altitude winds taking it to the east.

Landing Prediction

The Pi tracker includes software to predict the landing spot based on the wind measurements during ascent and the efficacy of the parachute, so I enabled that with a setting to make it appear as a large “X” on the live map. Onboard landing predictions are very useful when chasing especially if the online prediction isn’t available (e.g. no internet connection in the chase car). Here’s a video, made by Steve Randall, showing the two predictions plus the balloon position and chase car position; note that due to load on the server, the balloon and predictions are lagging 2-3 minutes behind the chase car position.

In the chase car, we saw that the online prediction was rather different from the on-board one. From experience, the latter is more likely to be correct, although it doesn’t take into account different winds at the landing site vs the launch site. I knew from running predictions earlier that the landing spot was moving north during the day, so figured that the actual landing point would be north of the on-board prediction, which was in the same direction as the online prediction. Checking on the map, we found a road that was close to this point, so we took that road and parked under the expected flight path. It took a while to spot the parachute, which I managed about a minute before it landed.

As it happens, the payload’s camera was busy photographing us as it flew over our heads!


With the landing position known, I chose the “Navigate to payload” function in my Android tablet app, and followed the instructions to a farmhouse about 250m from the landing spot. After a short chat with a resident we drove back to a public footpath and set out on foot with phone connected to a USB OTG LoRa receiver. The phone runs my HAB Explora app which gives directions to the payload. For a while it looked like the payload would be close to the path, but as we got closer we could see it was around 50 metres to our right. And to our right were …. trees.

So, back in the app, I chose the “Navigate off-road to payload” function. This loads up a separate mapping app (in this case BackCountry Navigator Pro) and tells it to provide directions to the payload. This showed us that the payload was actually at the far side of the trees, so we followed the path and edge of the fields round the trees to the payload.

The parachute was the first thing we saw, as it was up a tree! The balloon remnants and payloads were on the ground. The parachute was stuck fairly solidly but came free with a lot of force.

The camera payload obviously landed on one corner, and for next time I’ll add some extra foam to absorb the shock, because this is what happened …


And so, the aim of the flight, starting with a balloon selfie …

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.