LoRa LoRa Packets

One of the reasons for me experimenting with LoRa modules was that they are transceivers and should allow uplinks from the ground to a balloon, or communications between balloons.  Uplinks I will try on another flight, but for now I’m working on inter-balloon communications.

On previous flights my LoRa trackers have transmitted continuously, but this obviously won’t work if they are meant to listen to other trackers.  I opted for a very simple and widely used technique called TDMA (Time Division Multiple Access), with all trackers taking turns to transmit on the same frequency.  Timing was taken from the GPS which every tracker has anyway.  Time slots are static and written into the code for each tracker; during non-Tx periods, each tracker listens for packets from other trackers.

I set the frame time to 20 seconds, which conveniently divides exactly into 1 minute, making it much simpler to mentally convert from a time to a slot number.  Within those 20 seconds there are 10 usable 1-second slots and 10 1-second guard periods (to prevent transmissions from overlapping).  The frame begins on the minute, and there are 3 frames per minute.

I programmed 3 trackers for the flights, with each tracker having 1 slot to transmit its own position, and 2 slots to re-transmit packets from the other 2 trackers.  So together they can use up to 9 slots (3 direct, 6 repeats) out of the 10 available.


Here’s an SDR screenshot showing packets being transmitted every 2 seconds; the packets occupy a bit less than 1 second so there is slightly more than 1 second between packets:

On my previous LoRa flights the packets have taken rather more than 1 second.  This time I opted for a wider bandwidth (62.5kHz instead of my usual 20.8kHz) reduces the packet time to about 1/3rd.

There’s another reason for going to 62.5kHz.  The LoRa modules that I’ve used have been offset from each other up to 4kHz which, if using a 20.8kHz bandwidth, is enough to stop packets being received.  Since the allowed offset is a proportion of the bandwidth, then using a wider bandwidth reduces or eliminates the problem.

The downside using any bandwidth > 20.8kHz, on the 434MHz band in the UK at least, is that transmissions must be limited to a duty cycle of 10%.  At least, that’s according to my reading of IR2030.  I measured the Tx time of my tracker’s transmissions and, with 3 slots in 20 seconds, it works out at a duty cycle of just over 8%, so comfortably the right side of legality.

Another downside is that the available power is now spread across a wider bandwidth, so reducing the S/N ratio at the receiver, and thus the link budget.  Whether this is an issue or not would become clear during the flight.

For the flights, I programmed 3 trackers provided by Anthony Stirk.  Each has an ATmega 328P, UBlox MAX M8Q, HopeRF RFM98W,  and cutdown circuitry (not used this time).


Each ran the same code but with different settings for payload ID, primary slot number, and secondary (repeater) slot numbers.  Each went into a Hobbycraft foam egg, total weight with a plastic Estes 18″ parachute was about 70 grams.

LORA1 went up with a 500g balloon.  I then watched the incoming packets and saw that is was still happily repeating LORA2/3.  At about 4km altitude the first of the other ground stations (Phil Crump‘s LoRa gateway at his WebSDR site) started to receive LORA1 directly, and LORA2/3 indirectly; in fact the first packet received there was LORA2 –> LORA1 –> Phil’s gateway:

11:52:31 $$LORA2,161,11:52:27,51.95024,-2.54456,00141,0,0,12*C46E
11:52:35 $$LORA3,161,11:52:33,51.95029,-2.54451,00142,0,0,11*9985
11:52:41 $$LORA1,164,11:52:41,51.96063,-2.57614,03953,7,0,12*99C2

Very impressively, the same receiver picked up LORA2 when that was at just over 1.1km altitude, and rather below the radio horizon:

12:23:47 $$LORA2,255,12:23:47,51.94375,-2.53650,01190,1,0,12*2AA3

I think that pretty much puts to bed any worries about LoRa range at this bandwidth.

After the flight I received several receiver log files, and so far I’ve only had time to do some analysis on Phil’s.  From that file, the following chart shows the altitude plots for LORA1 and 2 (100 on the chart = max altitude for LORA1) and fraction of packets received (10 on the chart = 100%) directly from LORA1, or indirectly via LORA2:


During the portion of the flight where both LORA1 and LORA2 were high enough to be in range of the Phil’s gateway, 82% of LORA1’s packets were received directly, and 58% were received indirectly via LORA2.

LoRa one was heading for a field as it came into land.  Now, normally the actual landing position isn’t known because the range of a landed tracker is typically about 1 mile.  There have been exceptions, where either the chase car is close or the payload lands in a tree or on the side of a hill, but for the vast majority of flights the actual landing position is not known till later when the chase car arrives (and then only if the car receiver is uploading via GSM).  One of my aims, or at least hopes, for these flights was for one or both of the still-flying trackers to continue to repeat packets from the remaining tracker after it has landed.

So as LORA1 approached that field, all eyes were on the telemetry to see “how low can we go?”.  As the flight gets lower, static receiving stations start to drop out because the tracker is below their line-of-sight, till finally the closest station gets the last packet when the flight altitude is at maybe 500 metres or so.  Here’s part of the conversation on our IRC channel which, to me at least, felt like waiting for Apollo 13 to come out of radio blackout!

[15:14] <daveake> 861 repeated 
[15:15] <daveake> 639m repeated 
[15:15] <daveake> suspense is killing me lol
[15:17] <daveake> 344m repeated 
[15:17] <fsphil> .... 
[15:17] <Upu> go on :) 
[15:17] <fsphil> *tension* 
[15:17] Action: fsphil puts on dramatic music 
[15:17] <Upu> jcoxon - LORA1 is about to get repeated
              on the ground from a flying balloon 
[15:17] <daveake> this is like watching apollo 13 re-enter 
[15:17] <daveake> we hope 
[15:17] <daveake> 146m 
[15:17] <Upu> haha 
[15:17] <Upu> nice 
[15:17] <Laurenceb__> woot 
[15:18] <jcoxon> Upu oooo thats amazing 
[15:18] <Upu> nice one daveake 
[15:18] <Upu> have a beer :) 
[15:18] <craag> 80 
[15:18] <daveake> 80m WOOOO 
[15:18] <fsphil> lol 
[15:18] <craag> next one will be ground 
[15:18] <craag> 46!!! 
[15:18] <Laurenceb__> yes 
[15:18] <daveake> Exccellent :) 
[15:20] <craag> and another to confirm! awesome work 
[15:20] <jcoxon> the dream of hunting payloads with other payloads
[15:20] <fsphil> hah, that was definitly on the ground 
[15:20] <DL1SGP> Lora1 still being rxed 
[15:20] <craag> getting repeated by both too it seems 
[15:21] <daveake> hah 
[15:21] <daveake> Wow, this is great :) 
[15:21] <daveake> Can anyone confirm defintely repeated by both ? 
[15:22] <craag> I've received two copies of the same sentence... 
[15:22] <dbrooke> me too 
[15:22] <daveake> excellent 

And just to prove it, here’s a screenshot from the tracking map, showing a large list of receivers all receiving LORA1 after the latter has landed:


Back to Phil’s gateway’s log, here’s the section before and after LORA1 (altitude in red) lands.  The direct packets (yellow) stop before landing, but the repeated packets (blue) continue until shortly before LORA2 lands (green):



Not shown here, but LORA3 also repeated the landing position.  An excellent result.  And even better, the same happened when LORA2 landed – it was repeated by LORA3.

Well, I say “landed”, but LORA2 managed to stop on the edge of an office roof, where it currently remains until I can organise recovery:

LORA3 landed without airborne support of course, but was easily picked up from the chase car from over a mile away – a similar result to that which I’m used to with RTTY.

LORA1 however is missing – no signal and no payload at the landing position.  Hopefully whoever found it will get in touch.


Posted in Weather Balloon | Leave a comment

Raspberry Pi “Skycademy”

If you …

  1. Are a teacher or youth leader (e.g. scout group)
  2. Are interested in applications for the Raspberry Pi
  3. Would love to help your class or group send a weather balloon into the stratosphere and take live images throughout

… then read on.


In August, the Raspberry Pi Foundation are running a “Skycademy” aimed squarely at people like you.  Unlike other Picademys this will not focus on programming, but instead will cover all the vital elements you need to know in order to safely and successfully run your own near-space project.

The course will be run over 2.5 days:

  1. Overview of high altitude ballooning, with practical sessions (e.g. building your payload, setting up the balloon tracker and ground receiver, running flight predictions)
  2. Launch day (1 flight per 6 attendees)
  3. (half day) share photos and experiences from your flights
There is no single part of High altitude ballooning that is particularly complex, however it does cover a lot of separate activities and it’s vital that anyone launching a balloon has an understanding of them all.  Too many flights are lost or only found through luck, typically because the launchers concentrated on some aspects of the subject and did not think about others.  The primary aim of the course is to make sure that you have a good basic understanding of everything that you need to make sure your flight has the best chance of success.

So, if you want to inspire your kids to be engineers or scientists, or just open their eyes to how, with a small budget and a lot of duct tape, they can send their own payload up into the stratosphere, then apply here, and read more on the Raspberry Pi blog.

Applications for #skycademy close on Friday 10th July so hurry up!



Posted in Weather Balloon | 1 Comment

LoRa Calling Channel and Auto-Tune

When used for tracking high altitude balloons, LoRa has the potential for a receiver to be set up unattended on a permanent basis, but only if it can automatically set itself to the correct frequency, bandwidth and other settings for each flight.  Originally I intended these settings to be taken from a central database, but a rather neater solution was suggested yesterday on the #highaltitude IRC channel.  During a discussion of how to solve this problem, Philip Heron of SSDV fame suggested that each balloon announce its own parameters on a standard calling channel:

[15:45] <fsphil> I'd like a channel for announcements 
[15:45] <fsphil> "I'm on xxx MHz with these parameters"

Neat idea.

Fast-forward 24 hours to now, and I’ve coded this up in the LoRa section of my Pi In The Sky tracker software and also my LoRa gateway.  It wasn’t difficult and took about 3 hours altogether.

The tracker is configured with 2 settings:


The first setting specifies a calling frequency on which the tracker will periodically transmit a message telling listeners the frequency and parameters of its normal transmissions.  The second setting specifies how often this special message is sent (e.g. after every 5 normal messages).  The other parameters of this special message (bandwidth, spreading factor etc.) are fixed at present (probably a good idea for a calling channel!):


The message itself is very simple, e.g.:


and contains the payload ID, frequency in MHz, implicit/explicit mode, error coding, bandwidth, spreading factor and low-data-rate optimisation.

Here’s a sample packet seen on an Airspy SDR.  The calling packet is the one on the right (at 434.475MHz), followed by the start of a normal packet (on 434.400MHz):


The gateway has of course to be set to the calling frequency (434.475MHz in this case) and the correct set bandwidth etc. which are combined to together into a new “mode” of 5.  I have also enabled AFC (Automatic Frequency Control) using code written by David Brooke (thanks David!) – you can see his version of my LoRa gateway here.


The gateway shows the following screen when started:

d2Note that it says “Calling mode” at the top, next to the calling channel frequency.

Now let’s see what happens when it receives a calling packet:



The final message in the log at the bottom states that the new frequency is 434.405MHz; why not 434.400MHz as requested by the tracker?  The reason is that the receiver detected a frequency error of 4.6kHz (see the frequency error shown near the bottom of the blue section on the right).  As we have AFC enabled, the software automatically applied this error when it switched to the balloon tracker’s main frequency.  It’s better to do it now rather than later, especially if (as in this case) the balloon’s main transmission is using a narrower bandwidth where a large frequency error might prevent any packets being received.

So, now the gateway has tuned in to the balloon’s main frequency, and set the various LoRa parameters correctly, it should start receiving regular packets:

d4In this screenshot, it has received 13 such packets so far.  You may also notice that it has fine-tuned itself to the balloon main frequency, and now has a zero frequency error.



Posted in Weather Balloon | Leave a comment

Raspberry Pi Weather Station

I’ve recently put my Maplin weather station back online, feeding data to wunderground.com.  This is a live object that links to the site to show the current local weather conditions:

I bought mine from Maplin, where it is currently £99.99, however it is often substantially discounted during their sales.  It includes an outside station that measures wind strength and direction, temperature and humidity, linking wirelessly to a master unit with a large touchscreen LCD (fairly clear but not the best contrast) that has a USB port to connect to a computer.

The supplied software is ugly, unreliable and doesn’t do very much; it’s really not even worth the bother of installing.  Instead, I strongly recommend either using Cumulus of Pywws.

Cumulus is the simpler option.  It’s a Windows program and installs in a few seconds.  Configuration is easy via some setup screens where you can tell it what weather station you have, and what internet uploads to perform (e.g. to wunderground, APRS).  I ran this for a few days it worked very well.  The UI is quite nice and the software didn’t crash, though I did have to restart it once or twice when it lost contact with the weather station (I’m pretty sure this is a “feature” of some of these stations).

Running Cumulus continuously (do it uploads live data) does of course mean having a Windows PC on all the time.  This in turn means converting money into heat which you might not want to do especially in the summer months.  For both these reasons I turned to a solution that I could install on a Raspberry Pi.

I followed these excellent instructions to install pywws on a spare Raspberry Pi.  This needs to be a model B or B+ or V2 B, because it needs a USB port to connect to the weather station plus an internet connection (LAN or second USB for wireless LAN).

pywws can upload data periodically to your own web site for viewing, but I prefer to have it upload data live to wunderground.com.  To do this you need to create an account there (free), add the position of your weather station, and then enter the account details into the pywws weather.ini file.  Once it’s all working, wunderground.com will show live and historic data from your station:



Posted in Weather Balloon | 1 Comment

Partial Eclipse From Afar

Back in December I was approached by the BBC about launching a high altitude weather balloon flight during the forthcoming solar eclipse which was total over the Faroe Islands but approx 85-90% over much of the UK.

After some discussion we planned the flight to be from Leicester Racecourse where the BBC were holding a event for the public, with mainly school groups in the morning and open to everyone in the evening.  So no trip to the Faroes for me!

The aim for the launch was to get photographs of the eclipse from above the clouds (there are always clouds during a UK eclipse!).  To see the moon’s shadow would mean launching much further north, especially as the forecast winds meant that we had to limit the maximum altitude to about 30km.  We did though hope to get some filtered shots of the sun, to reveal the shape of the moon crossing.


For most balloon flights, it’s easy enough to delay the flight if the wind predictions compromise the flight or if the launch winds are too strong to launch in.  This time though we had one chance and one chance only!  Even delaying for an hour would mean that there’s little point in launching.  Flight predictions start coming in about 6 days before launch, though they usually do not start to get accurate until about 3 days prior.  It’s always tempting to check those initial, unreliable forecasts and sure enough I did so.  They looked OK, however as later predictions came in, the forecasts got worse, with the flight path going over London (bad) to land in Kent (a small target at that distance).  Worse, if the balloon burst early (which happens) the flight would land worryingly close to Gatwick.

I ran a few different scenarios, using larger or smaller balloons, each with more or less gas, and found no good flight paths at all.  A short flight would miss London but land in the rather built up area west of the M25 (and too close to Heathrow).  It became obvious that, if we were to launch from Leicester, the only safe flight would be a very slow ascent, to go south from Leicester, missing London, then turn east over the English Channel to make landfall near Dieppe!  We seriously considered doing just that, with a chase team setting off early to be in France ready for the landing, but logistically this was always going to be a pain (especially getting the video files back to Leicester in time).  We also looked at possibly launching from somewhere else.


Showing Tim just how crap a cheap Chinese aerial really is (answer: very)

Fortunately though, predictions continued to move the flight westward.  About 2 days prior to launch we could see the possibility of doing a “normal” flight to about 30km, landing not that far south of Leicester.  The only remaining worry was overshooting the landing spot and getting close to Luton Airport, so to avoid this we aimed for a point SW of Milton Keynes and used a Totex balloon (chosen for their reliability in bursting when they are supposed to!).  So, finally and to everyone’s considerable relief, we had a nice safe flight plan that would work.  As a bonus, the forecast ground winds were very low, so it looked like we would have an easy launch.


As this was a photographic flight, the payload was designed to allow for multiple cameras – both video cameras and Pi cameras connected to A+ boards and the PITS+ tracker board.  We used 4 Replay XD Prime X cameras, each pointing in a different direction:

  • Downward-facing wide-angle
  • Upward-facing moderate angle
  • Outwards-facing wide-angle (moderate downward angle about 22 degrees)
  • Outwards-facing narrow-angle (canted upward about 24 degrees) with solar filter

These are particularly nice cameras to use for HAB:

  • Field of view can be set to 70, 110 or 140 degrees
  • Can do full HD (1080p) at 50/60 fps
  • Easily mounted using plastic clips and strong 3M sticky pads



We mounted all 4 in a wide payload box (the idea being to reduce spin by increasing angular mass when compared to a normal payload box.  We placed 2 of the ReplayXD cameras at the ends of the box, alongside the Pi/PITS trackers, with battery packs a little way inboard.  The up/down cameras were placed more centrally for better views.  Here’s the complete payload prior to launch:


With the payload built, we checked the live images (working) and backup tracker (no GPS lock).  With a box full of electronics it was possible that the GPS was struggling with electrical noise, so we tidied the cables away from the GPS aerial, and added an extra tracker externally in its own ball.  Once that had a lock it was time to launch.  We’d been asked to let some schoolkids launch, so once Tim had posed with them …


… before launching …


Anthony then reported that the live images weren’t working.  Nothing we could do of course, as the flight was in the air and beyond reach!  It was only days later that I discovered that a recent change meant that, depending on timing, it was possible for the code to delete a converted image just before starting to send it.  Once this happens, it doesn’t send that image and thus doesn’t trigger the conversion of the next image, so no more images are sent until a reboot.  However it didn’t stop the images being taken so we did get plenty of images once the flight was recovered.

I didn’t get much time to think about what was wrong, or worry about it, because I was soon needed for a live TV appearance.  We’d practiced the interview (live TV is rehearsed a lot!) but we had to change the plan slightly because of the lack of live images, and decided not to show any images (we had some from other flights).  However nobody told the interviewer so she still asked to see an image and I had to swiftly load up a suitable image on the laptop!  You can see the entire program on iPlayer or just my section.


With that out of the way, it was time to watch the eclipse itself!  Here’s a short timelapse taken by Tim, using my 600mm mirror lens with a sheet of solar film taped over the end:

Then came another TV spot:

After that, it was time to check up on the flight.  Here’s the map on the big screen during my interview …


and here it is on a rather smaller screen inside …



As I mentioned, we aimed for a “standard” flight and the exact targets were a 5m/s ascent rate, 5m/s descent rate and a burst a little past 30km.  I knew that we’d be slightly off because of the extra tracker added at the last moment, and this reduced the ascent rate slightly and moved the landing point a few miles south.  The balloon popped pretty much when expected, at 30,750 metres and the predicted landing spot was just south of Leighton Buzzard.  Here’s the burst video which we retrieved later:

Ironically, having launched from a racecourse devoid of horses, the flight landed in a random field with several of them in attendance!


Here’s a view of the landing from the upward-facing camera.  Keep watching till the end :-)

About lunchtime, I was collared by the BBC Radio Leicester team, who wanted me to do a live interview for them.  This was actually much nicer than the TV stuff – instead of having to cut what I said down to as short as possible, I was allowed to rabbit on and on!  Click here for the 5-minute slot.


Meanwhile, our chase team (Anthony Stirk and David Bowkis) were busy collecting and returning the payload.  The landing spot was in a field near to a road, so their task was very easy!  Once they got back to Leicester, we started copying all the SD cards from the cameras, and I booted up the Raspberry Pi boards to copy the still images from those.


With the SD cards copied, Tim went off to see the BBC production guys to help choose what footage would be shown in the evening live TV show.  By now we were all exhausted and hungry, so we got some food at the canteen and sat outside in the sun to relax a bit before the evening show started.  As before, there were lots of rehearsals and we must have cut the slot down to about half the time of the first take.  I don’t know if it was the rehearsals or the lack of rest, but by now I wasn’t at all anxious about appearing on live telly and I was surprisingly relaxed as I waited for us to go live.

IMG_1058 IMG_1040

Here’s a pic just before they switched from Jodrell Bank to Leicester.  Hey, I’m on TV next to Brian Cox :-)


and here’s the live slot, recorded from TV:

and as recorded by Julie:

Finally, here are some stills from the flight videos.

nice nice2 nice3 rubbish


Posted in Weather Balloon | Leave a comment

Pi Party Presentation

As promised, a link to my presentation yesterday at the Pi Party, plus some useful links (from the presentation) for those wanting to know more:

Pi Party Presentation



Posted in Weather Balloon | Leave a comment

High Altitude Ballooning, From The Ground Up (and back again)

High Altitude Ballooning makes for a challenging project that sometimes turns into an engrossing hobby.  Whilst it’s not “rocket science” it does encompass a wide range of fields (sometimes literally) and there’s a lot to learn before you send your first flight up into the sky.

A failed flight (and these can happen even to the most experienced) is a sad thing, but you can maximise your chances of success by following this guide, and remembering these 3 points:

  • Do your research
  • Do plenty of testing
  • Do not rush

Research is vital.  Read up on existing projects – many people run blogs or have web sites showing how they developed their flights.  The UKHAS wiki is invaluable and is probably the best single source of HAB information on the internet.

Testing is vital.  If you’re developing your own tracker hardware and/or software, then you have plenty more testing to do – does it work in the cold?  does the software work across meridians?  how long do the batteries last?  Even if you buy a ready-made radio tracker, you need to test your tracking setup and skills.  Don’t leave that to the flight itself – it will all go terribly wrong.

Do not rush.  My very first flight took 5 months from the idea to the execution.  Overall it was a success although some things did go wrong.  Not many flights are perfect in every way, so please do everything you can to make your flight the best it can be.  Do not set a launch date before you are ready  – this is a tried and well tested method of ensuring failure.


High Altitude Ballooning is all about sending up a payload (containing tracking equipment and often sensors and/or cameras) to a high altitude.  Typical flights get to 30km or so (about 100,000 feet), with the balloon expanding from a typical 1 metre or so diameter at ground level to 8 metres or so at altitude, where the latex gives way and the payload falls by parachute to the ground.

Sounds simple, right?

It is, but you probably have (and should have) many questions, for example where can I get one of these balloons?  How much gas?  How do I get that gas inside the balloon?  How do I get permission for the flight?  How can I tell it where it will land?  How do I find it afterwards?  Read on for the answers.


This comes first because it’s the most important factor in recovering your payload.  If tracking doesn’t work then all you’ve done is launch a big fat party balloon.

The best method of tracking depends on where you are launching.  Here I will concentrate on the UKHAS 70cm system because in the UK that is by far the best option as we have a wide tracking network that will help you track during your flight.  There are however other options:

  • GSM/GPS trackers.  These receive GPS data and they also connect to the GSM mobile phone network.  Models vary but typically you call the number of the SIM card in the device, and it texts you back with its position.  These are cheap and simple devices, however they very often do not work at all during a HAB flight.  Sometimes they land outside GSM coverage (and remember that even if you have a phone signal, a device on the ground next to you may not), or they get confused at altitude and never start working again.  Overall they seem to have about a 50% chance of working.  That figure, in my opinion and I hope yours, is nowhere near good enough.
  • SPOT tracker.  Similar idea, but using the Iridium satellite network instead of GSM.  These devices are much more expensive, so if they fail then you have lost a lot more money than with a GSM tracker.  They do fail, particularly if they land upside down, though I have no figures to quote.  Another issue, and one that they share with GSM trackers, is that they do not work throughout the flight.  GSM trackers will stop working at an altitude of a few hundred metres, and SPOT will work up to 12km, but even that accounts for less than half of the flight.  So, sometime after launch, you will not know where your flight is.  You won’t know when it has burst, and you won’t have a live prediction of where it will land.
  • APRS.  This is an Amateur Radio system that can be used to track balloons, but with 2 restrictions.  First, airborne amateur radio is not allowed in all countries (e.g. it is not allowed in the UK, but is in the USA).  Second, you have to have an appropriate amateur radio licence.  In the USA for example, the basic “Technician License” is enough, and you can then make use of the extensive APRS network in that country.
  • UKHAS Radio Tracker.  This system was developed in the UK, which now has a very extensive network of listening stations, but it has been used in many other countries even by sole trackers (i.e. the person launching is the only person receiving the signals).  Trackers are now available online for purchase, or you can build and code your own.  This part is very rewarding, and it’s how I started on my first balloon flight.  As well as the reward of knowing that your own hardware and software has been to “near space”, it slows down the process meaning that you will have more time to do that research I mentioned.

UKHAS Radio Network



The above shows how the UKHAS system works.  Your balloon carries a radio tracker that sends its position (and perhaps sensor data, or even images) down to the ground, where it is received by one or more listening stations.  I strongly recommend that you set up 2 such stations – one at a fixed location (e.g. launch site, home, school) and one in the chase car.  In addition, if you are in a country where there are existing listeners (the UK and Poland have good networks, and there are listeners in many other European countries) then if you inform them of your flight, they will listen out for it.  However do not rely on them – the responsibility for tracking your flight is your own.  In many countries you will be the closest, and therefore most important, listener to the payload as it lands.  Also, if you aren’t tracking at the launch site, you won’t know if the tracker is working.  Do not launch unless your tracker is working.

UKHAS Radio Tracker

A typical radio tracker comprises a GPS receiver (UBlox models are very popular as they work at up to 50km altitude), a radio transmitter (Radiometrix NTX2B-FA is very popular as it’s reliable, stable (the frequency does not drift as it gets colder), and frequency agile (so you can set the radio frequency away from those used by any other balloon flights in the air at the same time), and a small microprocessor (e.g. AVR (Arduinos are popular) or a PIC).

Soldering a tracker together is easy for anyone who can solder anything.  The UBlox devices can be purchased on breakout boards, so all you need is one of those, an Arduino prototyping board and that radio transmitter, then you can build a tracker in less than an hour.

There’s a guide to show how to connect a radio transmitter to an Arduino.

Here’s a nicely laid out radio tracker showing just how simple this can be:


UKHAS Receiving Station

As above, you should set up a station at a fixed location, plus a separate station in the chase car.  You will need (for each station):

  1. Receiving aerial.  This has to be one designed for use on the 70cm band.  Many such aerials are “2m/70cm” dual-frequency designs.  For the fixed station the main thing is to get the aerial up high so it has a clear view of the horizon.  A “colinear” aerial is a good choice.  For the chase car, use a magnetic-mount whip aerial.  I also recommend taking a small Yagi aerial in the car, for direction-finding or for decoding a weak signal, after the flight has landed.
  2. Radio.  You can choose from a traditional radio (a radio scanner or amateur radio transceiver – so long as it can do “SSB” on “70cm/434MHz” then it will be fine), or an SDR (Software Defined Radio, such as a cheap TV dongle or a (much better) Funcube Dongle or (better still) AirSpy.  See the UKHAS tracking guide for some example radios and how to track, and the UKHAS SDR guide for more information on tracking with an SDR.
  3. If you are using a radio (not an SDR) then you need a 3.5mm audio cable to connect the earphone socket on the radio to the line in on a PC or laptop.
  4. A PC/laptop to decode the signals and to upload the resulting data (telemetry and perhaps images) to the UKHAS servers.
  5. Software.  e.g. HDSDR or SDRSharp for the SDR, VAC to connect the SDR audio to the decoding program, and dl-flgdigi to decode and upload.  All these are explained and linked to in the above guides.

UKHAS Uploading

dl-fldigi will decode the signal (i.e. convert the bleeps and whistles into data) and will then upload that data to the UKHAS servers.  However, those servers need to know what information to expect from your payload.  This is done using a “Payload Document” which describes what fields (e.g. latitude, longitude, altitude, temperature, pressure) your payload is transmitting.

To create a payload document, go to the UKHAS Payload Generator.  If you wrote the tracker code yourself then you will of course know exactly what it is sending.  If instead you are using a pre-built tracker with the supplied software, then refer to the supplier’s documentation.

Once the payload document exists, and dl-fldigi is decoding and uploading, then your payload should appear on the live map.  If it fails to appear, then probably the payload document is wrong – see the logtail which will show you why.

Prior to your flight, create a Flight Document.  This tells others where and when your flight will be, and allows them to easily set the correct radio frequency and decoding parameters for your flight.

Payload Design and Build

Here you can use your imagination to build something visually interesting, but remember the following key points:

  1. Use plenty of insulation.  2cm is generally enough but use more for heavy payloads (though heavy payloads are discouraged anyway) or 1cm for light payloads.  Insulation does 3 things:
    1. Protects whatever your payload lands on (remember, it could be a car or person or greenhouse)
    2. Protects the tracker and cameras etc from that impact
    3. Protects the tracker and cameras from the cold
  2. Suitable insulation can be purchased from some DIY stores or online at Hindleys.  Choose from the lighter but soft white expanded foam polystyrene, or the heavier but stiffer extruded foam polystyrene (easier to cut accurately).  Or, for small payloads, you can buy small polystyrene boxes or hollow polystyrene balls from Hobbycraft.
  3. Make sure that anything inside the payload cannot move during flight.  The burst and landing are both violent affairs.  If your payload can’t survive a fall down stairs, then it’s not going to survive a flight either.
  4. The transmitting aerial should be on the underside of the payload container.
  5. The GPS aerial should be near the top of the container, with a clear view (one unobstructed by anything metal such as cameras or batteries) of the sky.
  6. Design the container so that it’s easy to put the cameras inside.  Some cameras, especially video cameras, have a limited run time and so there will be a time restriction between starting the camera and having to launch.  If possible arrange the payload so that the camera can be started after the payload is closed up for launch.
  7. Keep the entire payload as light as practical.
  8. Try to keep heavy items to the bottom
  9. Try to keep it balanced – e.g. if you have 2 cameras put them on opposite walls
  10. Try to design in support lines to attach to the parachute, otherwise you’ll have to tape them on outside (ugly and not as secure as embedding the lines in the walls, for example).

As an example, see my TARDIS payload, which included support lines embedded in the walls, heavy items (batteries) at the bottom, UHF aerial underneath and GPS aerial near the top.  Everything fixed to the base, so the batteries could be inserted and everything checked before the top (body) was put on.

If you are making the payload box from sheets, use a sharp knife or a hot-wire cutter to cut.  Remember that the white expanded foam can make a lot of mess unless you use a really sharp knife, which is one reason that I prefer the slightly heavier extruded foam.  For glue, do not use a standard solvent glue as it will destroy the foam.  Only use UHU Por which is designed for the task.  Hot-melt glue is an alternative but beware that the glue can get hot enough to melt the foam.  Some guns have 2 heat settings and those are safe to use on the lower setting.

Final closure of the payload can be done with duct tape, which is available in a wide range of colours to suit your aesthetic needs, and not just silver-grey!


There are 3 main options for near-space photography:

  • Stills camera that can be programmed to (for example) take 1 image every 10 seconds.  The Canon Powershot range is very popular for this, as they can be programmed using a simple script and the CHDK downloadable software, and many of them can be powered by the reliable Energizer AA Lithium batteries.
  • Video “action” camera.  The GoPro Hero2/3 models are ubiquitous, but you may not care for the severe barrel distortion.  They are sharp though and work well.  Remember to test the run time (which can be limited by battery power and/or SD card capacity); use a larger battery / SD card to give you the run time that you need (3 hours is about enough).
  • Processor board and camera – e.g. the Raspberry Pi and camera.  If you are using the Pi as a tracker then it is an obvious choice to use its camera also (and if you’re not using its camera, why are you using the Pi as a tracker?).  The combination does have a few advantages:
    • Lighter than a GoPro
    • Doesn’t have the gross lens distortion
    • Can do tracking as well as imagery
    • Can transmit images
    • Very programmable – e.g. change image size or frequency depending on altitude.

A popular question is “Should I use a case for the camera?”.  The GoPro for example comes with a case, with clear lens, to protect it from impact during use.  Do not use a case.  It will very likely trap any airborne moisture inside the case, where it will eventually condense on the coldest part of the case which is directly in front of the camera lens.

Balloons and Parachutes

Balloons come in various sizes and from 3 main manufacturers.  For the widest choice and best service buy from Random Engineering.

All the above parachutes have loops at the top for attachment to the balloon.  Choose the size using the calculator on that page, aiming for a landing speed of 4-5 metres per second.  You will need to know the payload weight, which you can estimate by adding together the weights of the heavier items and allowing 100g for the container and duct tape.

The larger the balloon, the higher the flight will go and, usually, the further it will land from the launch site.  Anything above 25km will get good photographs, and 30km is a good figure to aim for.  A typical size might be a 800g or 1000g balloon, but you should use the calculator to find out what size balloon you need for what altitude.  Aim for an ascent rate of 5-6 metres per second, and remember that your payload weight should now include the weight of the parachute.

The calculator will tell you several things, and not just the burst altitude:


  • Payload Mass includes your parachute and the rigging (braided nylon cord).  As a rough guide use 100g for both, but you can get the parachute weight from the store above, and you can weigh the cord.
  • Target Ascent Rate should be 5m/s.  The calculator will then show a slightly different rate (see bottom left), and you can adjust your target for this to be 5m/s.  Do not go lower than 5 as you risk the balloon not bursting.
  • Volume shows how much gas you need.  Most balloons will need less than 3.6 cubic metres which is a BOC “T” cylinder, costing about £100.  Try not to go above this figure as the next size up (“L”) is huge.
  • The Neck Lift tells you how much lift the balloon has when filled with the above volume.  If you attached something of this weight to the balloon, then the balloon will hang in the air without going up or down.  See the section on Filling below for more information about this.


In the UK, you must obtain permission from the CAA.  No permission means no launch.  Click here for more information and a downloadable form.

The CAA request that you send the form in at least 28 days prior to launch, and I recommend that you do just that.  However you will not know at that point if you will be able to launch on the date you requested.  So I recommend the following:

  1. Choose a launch site,  If this is near an airport then you will either be denied permission, or it will come with restrictions as to what time you can launch and/or in what direction the balloon must fly after launch.  I recommend you find a better launch site if this is likely!
  2. Choose a date.  Check online to see if there are any local airshows (these are, in my experience, the most likely reason for denying permission).
  3. If the date is at a weekend, request both Saturday and Sunday
  4. Fill in the form, and send to the CAA together with the required map.
  5. Wait
  6. About 6 days prior to launch, start checking the flight path predictions (see below) and the ground wind predictions (Wunderground is good for this).  Do this each day.
  7. In light of the above predictions, if you think that the flight will be able to go ahead, then send an email to AUSOPS at the CAA, a few days before the flight, referencing your application and confirming that you believe the flight is likely.
  8. If instead you can see that the flight won’t be able to happen, let the CAA know at least 2 days before the flight (if the flight is at the weekend let them know by Thursday at the latest), so they don’t waste time processing your request.
  9. The last working day before launch, check the AIS site and/or notaminfo.com.  Usually you will find out here that your NOTAM has been issued, before the CAA permission certificate comes through.
  10. My experience is that permission comes through late in the afternoon.  I realise that you may become nervous that nothing appears to be happening, but provided you sent in the confirmation email that I recommended then permission will be issued (this has been my experience anyway).

If permission does not arrive before the launch, do not launch.  If the permission includes restrictions (e.g. on the wind direction) that you cannot meet, do not launch.  Remember that obtaining permission is a critical safety step in the process.


Even with permission, you should only launch with a safe flight path.  This primarily means having a landing area that is well away from cities, large towns, airports or motorways.  Remember that balloons may burst rather lower or higher than you planned for, due to manufacturing tolerances or your ability to fill the balloon with the correct amount of gas (see section on Filling below), so you should run predictions for early or late bursts as well as your planned burst altitude.

Also, do not plan a flight that lands close to the sea.  No flight exactly follows the prediction.  There are many variables such as the accuracy of the wind forecasts and (especially) the amount of gas put into the balloon, and as a rule of thumb I suggest you allow for a landing error of at least 5 mile radius, with an additional “distance from launch” error of 5% of the distance travelled.  So a typical 100 mile flight would have a possible landing area of approx 10 miles long (in the distance travelled) by 5 miles wide (at right angles).

You can run a prediction online using the CUSF Flight Predictor.  This works up to about 6 days prior to the flight, but generally does not start to be accurate until about 3 days prior.  It is worth running a prediction every day up to launch, to gauge how much they change from day to day – if they don’t change much then you will know that the prediction is quite predictable, which is good.

Another thing to check is how much the prediction changes from hour to hour during the launch day.  Launches frequently (in fact, almost always, run late) and you should run a prediction for 1 hour after launch, as well as at the target launch time, to see if it changes much.  A large change is bad because it makes the landing spot highly dependent on what time you launch.

As you run predictions, you will probably notice that the balloon direction changes throughout the flight.  This is because the wind travels in layers with different layers travelling in different directions and/or at different speeds.  Generally, ground level winds travel from west to east, but of course any direction is possible.  Higher level winds tend, in the summer months, to travel from east to west meaning that your balloon will at some point reverse its direction.  Here’s a typical example, with the flight travelling south, then east, then north, then west on the way up, and then turning in the opposite direction during descent:

In the winter months, much depends on the jet stream.  If you balloon hits this then it will be swept towards the continent at up to 200mph, making a UK landing impossible and recovery difficult.

Remember to run a final prediction soon before your launch, so you have the most accurate data.

Balloon Neck Lift

The section on Balloons earlier mentioned a thing called “Neck Lift”, which you need to know in order to fill the balloon with the correct amount of gas.  Newcomers seem to get confused about what this number means, so I should explain.

For simplicity, I will assume a 1kg balloon and a weight of 1kg for the payload and parachute.  Obviously if you put the balloon on some scales, it will register (give or take a few grams) 1kg.  Now let’s put some helium gas inside.  As the helium fills the balloon, the balloon starts to displace the surrounding air.  Because we are displacing air (which has a mass of over 1kg per cubic metre) with helium (which has a mass of about 10% of that), the more gas we put in the lighter the balloon becomes.  At about 1 cubic metre of gas, the balloon will be light enough to just lift off the ground.

Of course at this point the balloon isn’t much use to us – we need it to lift the payload too!  So we’ll put about 1 more cubic metre inside.  Now we’ve displaced enough air to give us about 1kg of lift.  Remember that our payload is 1kg, so if we closed off the balloon neck at this point and attached the payload, it’s going nowhere!  We need more lift to take the payload up into the air.  As it happens, we need about 1 more kg of lift and so about 1 more cubic metre of helium.  Here’s a calculation for this example:


So that’s how the gas provides enough lift to send the balloon and payload up into the air, but how do we know we’ve put the correct amount of gas inside the balloon?  That’s where the neck lift comes in.  Remember that for the above example, we wanted 1kg to just lift the payload, and another 1kg to send the payload up at the right speed (5 metres per second), so that’s a total of 2kg.  This is the “Neck Lift” and is 2.082kg in the screenshot above.  Neck Lift is how much upward pull the balloon has.  So now we know what it is, how to measure it?


To fill a weather balloon, you need something to get the helium from the cylinder to the balloon.  We call this a “filler” or “filling assembly”, and it’s basically a length of ordinary garden hose but with a fitting at each end.

The balloon opening (or “neck”) is a large diameter tube of relatively thick latex.  It’s much too large to fit over the hose, so instead we fit the hose inside a larger tube (typically standard 40mm waste pipe which is sold by any DIY store).  The gap between that tube and the hose needs to be filled with something that won’t leak gas.  Expanded foam filler (also from a DIY store) is a common but rather messy choice.  Or you can use a length of pipe insulation (also from … OK you know), sealed at each end with silicone sealant (guess…).  Try this guide for how to make one.

The helium cylinder will come with a valve/regulator/filler that screws in to the top of the cylinder.  There are 2 designs of these device, but for either you should be able to squeeze the hose over the opening and fix it down with a combination of duct tape and hose clips.

Suppose that the filler assembly (see below) weighs 300g, and you want a neck lift of 2kg.  If you can attach something weighing 1.7kg (2.0 – 0.3) to the top of the balloon filler, then when the balloon has the desired neck lift (2kg) it will just be able to lift the filler (0.3kg) and added weight (1.7kg).

The one problem with the above is the wind.  Any wind will try to move the balloon sideways.  If you’re holding the balloon (to fill it) then the air going past the balloon will produce lift.  If you measure the total lift then it will include this aerodynamic lift, so you can only measure the neck lift accurately when there is no wind.  A slight wind is OK – carefully let go of the balloon and see if it goes up or down, before grabbing it quickly!  Or wait for the wind to stop or at least calm down enough for you to let go briefly.

As a rule of thumb, if the predicted winds are stronger than 10mph, postpone the launch.

Bill Of Materials

This is an approximate list, to use as a starting point.  Don’t go buying anything until you have a good understanding of the entire project.  Some items (e.g. parachute, balloon) depend on the weight of many of the other items, so these should be the last things you buy and not the first.  I often get emails asking me for a list of items to buy, and it’s an impossible question to answer.  Moreover, it’s the wrong question – it should be “what do I need to learn to make my flight safe and successful?”, and everything else should follow from that.

That said, here’s a list to help you make your own list.

  • Tracker (or trackers – a backup is a good idea).  I hope that you’re going to make your own radio tracker, in which case you need to buy:
    • UBlox GPS receiver
    • Radiometrix NTX2B radio transmitter
    • Processor board (e.g. Arduino)
    • Battery holder
    • Coax cable for the radio aerial

A good place for GPS receivers, radios etc is HAB Supplies.

Or you can buy a ready-made radio tracker (e.g. Pi In The Sky, HABduino)

A GSM-GPS tracker is useful as a backup, or if you contact someone in UKHAS they may be willing to supply a spare tracker – useful if you’ve built your own and don’t know for sure that it will work.

  • Payload materials:Expanded or Extruded Foam Polystyrene (sheets or ready-made ball or box or egg)
    • UHU Por glue
    • Duct Tape
    • Waterproof label with your name / phone number / email address
  • Flight Train:Balloon
    • Parachute
    • Cable Ties
    • Braided Nylon Cord
    • More Duct Tape
  • Tracking Base Station:PC or laptop with internet connection
    • Radio receiver (SDR or real one with audio cable)
    • Aerial (colinear or 1/4-wave)
    • Coax cable from aerial to radio
  • Launch Kit
    • Ground sheet (tarpaulin)
    • Filler Assembly (waste pipe, insulation, silicone sealant, yet more duct tape)
    • Water bottle (to check the neck lift)
    • Water (for above)
    • Scales (to measure weight of said bottle of water)
    • Cable ties
    • Duct tape
    • Scissors
    • Wire Cutters
    • Gloves
  • Chase Car Kit
    • Receiving Station / Live Map:
      • Magmount aerial
      • Radio (real (preferred) or SDR)
      • Laptop or netbook or tablet or phone with decoding software
      • 3G connection (MiFi or a phone with 3G/WiFi tethering)
    • Car uploader – this puts your car on the live map so others can see where you are as well as the balloon.  You can use a USB GPS on the laptop/netbook, or use a suitable program on a phone or tablet.
    • Yagi aerial (for picking up a weak signal after the payload lands, or for direction-finding if it’s really weak)
    • Wellies and/or walking boots
    • Sat Nav
    • Car Chargers for Phone/Tablet/Netbook/Laptop/MiFi.
    • Real map

Launch Day

So, the big day has come.  Your tracker has been working for weeks now, and you’ve tested that you can track it on the ground from a mile away.  You have permission from the CAA and your flight predictions show a nice landing far away from any hazards.  Your base station is set up and you’re ready to put the kit in the car for the chase.  You have the balloon, gas, filling rig, ground sheet, parachute, completed payload, cord and plenty of duct tape.  You’ve created both payload and flight documents, you’ve seen your balloon on the map, and you’ve alerted the other UK balloonists of your flight.  You’re ready to launch!


Get the car unloaded.  Put a table up if you have one (much nicer to work on a table than the ground when your putting the final touches to the payload, or getting your laptop tracking set up).  Lay out the ground sheet and peg or put weights on the corners to stop it taking off.  Put the cylinder and filler on the ground sheet, together with the other items that the person filling the balloon will need.


The tracker is the first thing to get working.  Make sure that you can receive and decode the transmissions.  Wait till it has a GPS lock.  Make sure that you have internet connectivity and that the balloon has appeared on the live map.  Make sure you’re using new batteries and not ones you’ve been testing with!


Put the tracker inside the payload box, and connect the aerial to the tracker.  Check the tracker is still working.  Make sure all cameras have fresh / fully charged batteries.  Make sure the SD cards are empty of all images!  Start up the cameras, and photograph your contact label in case the label is lost during the flight but the camera is recovered.  Preferably put one label inside and another on the outside.

Start the cameras recording stills/video.  Insert the cameras and close off the payload lid (fix it down with tape).  Check that the tracker is still working and still has a GPS lock.  Check that the cameras are still recording.

Payload Train

Measure roughly 10 metres of braided nylon cord out.  Tie one end to the top of the payload, and the other end to the bottom of the parachute.  Measure out another 5 metres of cord, and tie one end to the top of the parachute.

All knots should be pulled hard to make sure that they do not slip at all.  Remember that these are the only things stopping you from dropping a payload from 30km up without a parachute.  Put a piece of tape over each knot to stop it coming apart.

Put the free end of the top line (the one above the parachute) on the ground near to the person filling the balloon.


Now it is time to fill the balloon.  Remove it from the wrapper and lay it out on the ground sheet.  Fit the filler assembly to the helium cylinder and make sure it’s a tight fit.  Open the cylinder valve.

Fit the balloon neck over your filler tube, leaving enough of the beck free for sealing later.  Then tape down with duct tape over the end.  Fit 2 cable ties to stop the balloon from escaping.

Check the weight of your water bottle, making sure that it matches your neck lift calculation taking into account the weight of the filler.  Attach the bottle to the filler with cable ties.

Open the gas valve and allow the balloon to fill.  Fill until it can hold the water bottle in the air without the bottle coming back down.  If it’s windy, wait for a lull in the wind before doing this.  If in doubt add more gas.

When you have enough gas, tie 2 cable ties around the neck of the balloon, about 10-20mm apart.  Get someone to come over and help at this point.  Tie the free end of the top line around the balloon.  Cut off the cable tie ends and put tape over the knot and cut ends.  Wrap the line around the cylinder or have someone hold it (they must wear gloves) to stop the balloon escaping if you slip up.  Have someone hold the balloon neck (where that line goes) whilst you remove the cable ties that are holding the balloon neck on the filler tube, and remove the tape.  Fold the balloon neck back over itself, put on one more cable tie, cut off the loose end and tape over it.


First, check that the tracker still has a GPS lock and you are decoding the transmissions.  Check that all cameras are still recording.  Check that the payload train is tied together properly and that no idiot put the parachute on upside-down.

If your CAA permission tells you to call Air Traffic Control for clearance, do that now.  Follow their instructions (they may well ask you to wait for an aircraft to pass).

Have someone hold the payload.

Check the sky for planes – look and listen.

Start allowing the balloon to rise.  Gloves are very, very important for this bit as you could get a bad cut from the nylon line.  Lift the line up, keeping a good grip at all times, feeding the parachute through your hands and keep going till you are holding the payload.

Check the sky again.

Now it’s time to let go!  So long as it’s not windy, then this is easy.  If it is windy, you will find that the balloon isn’t above you, but is about 15 metres away and possibly only a couple of metres above the ground.  See if you can wait for the wind to let up, at which point the balloon will start to rise.  Start walking towards the balloon, and it should rise.  Walk faster, allowing the balloon to rise till the line is almost vertical.  You may well need to run at this point.  Do not release until you can see that when you let go the payload will go up (or at least horizontally) and not down into the ground!


Once everything is packed up you can set off after the balloon.  Generally, the best plan is to make sure you’re not far from the balloon when it bursts.  You may well be tempted to drive straight to the expected landing point, but that’s generally a bad idea as you won’t know the landing area until after the burst.

Whatever you do, try and be near the intersection of 2 major roads so that you can head off in any direction once the balloon has burst and the landing prediction starts to be more accurate.

You can then head for the expected landing point shown by the live map. Again, try to find a good road junction to park near.  Or, if it’s a hilly area, the best idea is to get to the top of a nearby hill; this is much better than being in a valley where the radio signal is likely to cut off early.


When the payload has landed, the signal will probably stop.  If it hasn’t stopped, then either you managed to find a place very close to the landing position (typically within 1 mile) or it’s in a tree!

If you don’t have a final position, then getting one is your absolute top priority.  Drive to the latest payload position that you do have, or to the predicted landing spot (shown by the live map).  Use the yagi aerial if the signal is too weak to decode, or find a small hill to drive up.  So long as you can get to within 1 mile of the payload, without a hill in the way, you should get a decodable signal.

Once you have the final position, write it down and tap it into a sat nav.  Drive to the closest you can by road.  If you have a 3G signal, switch the live map to satellite view and see where the payload is and how you’re going to get there.  Or, use Back Country Navigator Pro on a tablet or phone, to view where you are and where the payload is on an Ordnance Survey map (download the map before the flight!).

Almost always, the flight will be on private land so you should always try and find the landowner and get permission.


Posted in Weather Balloon | 4 Comments

Making a LoRa Gateway

One of the advantages of the LoRa transceivers, when compared to the traditional RTTY modulation used by most High Altitude Balloons, is that it requires very little processing power at the receiver.  So instead of using a PC or a high end tablet or phone to decode the transmissions, all you need is a simple microprocessor with (assuming you want to upload data to the web for mapping) an internet connection.

The latter requirement makes devices such as the Raspberry Pi ideal for the task.  A Pi, plus wired or wireless connection, just needs a simple board added with a LoRa transceiver connected to the SPI pins.  And that’s exactly what HAB Supplies has made – and here’s a prototype board that they sent to me:


Normally it comes with a single 434MHz LoRa device but here I’ve added a second (you could add a 434MHz or 868MHz model).  The remainder of this post will assume that the board is populated with just one device, in position 1.

Physically install is very simple – just push on to the Pi model A+ or B+, using a standard pin header extender (supplied).  Or an pin header with extended pins can be used if you want to stack another board on top.

Next, burn an operating system onto a suitable SD card.  For this purpose anything from 4GB should be fine.  The following instructions are for Raspbian, and no other operating systems have been tested.

First, run raspi-config:

sudo raspi-config

Then expand the filesystem, as you would normally do, then choose Advanced Options –> SPI and enable SPI.


It’s also worthwhile to change the hostname (Advanced Options –> Hostname).  Finally, close the program and choose the reboot option.

Once rebooted, login again.  We now have some software to install.  First, install wiringPi, which is used for the SPI library and to read the status of the LoRa module via 2 of its INT pins:

cd ~
git clone git://git.drogon.net/wiringPi
cd wiringPi

Next, install SSDV which is used to decode download images:

cd ~
git clone https://github.com/fsphil/ssdv.git
cd ssdv
sudo make install

The gateway software uses the curl library for internet access (uploading telemetry data and/or image data), so install that:

sudo apt-get install libcurl4-openssl-dev

and the ncurses library used for the screen display:

sudo apt-get install libncurses5-dev

Finally, install the gateway software itself:

cd ~
git clone https://github.com/PiInTheSky/lora-gateway.git
cd lora-gateway

That completes the installation, so now for the configuration.  The main settings are in a file gateway.txt in the above folder (/home/pi/lora-gateway).  Here’s a simple example:




This firstly sets your callsign, which if you are a radio amateur would normally be your radio callsign, but it can be something else.

The next part sets the frequency and mode for the first LoRa device (the one in position “1”).  Frequency is in MHz and should match the frequency of the tracker that you intend to receive.  “Mode” is described below, where the other (optional) settings are also described.  The final lines are commented out, to disable the second LoRa module.

tracker=<callsign>.  This is whatever callsign you want to appear as on the tracking map and/or SSDV page.

EnableHabitat=<Yes/No>.  Enables/disables telemetry upload to habitat.

EnableSSDV=<Yes/No>.  Enables/disables image upload to the SSDV server.

frequency_<n>=<freq in MHz>.  This sets the frequency for LoRa module <n> (0 for first, 1 for second).  e.g. frequency_0=434.450

mode_<n>=<mode>.  Sets the "mode" for the selected LoRa module.  This offers a simple way of setting the various
                LoRa parameters (SF etc.) in one go.  The modes are:

                0 = (normal for telemetry)  Explicit mode, Error coding 4:8, Bandwidth 20.8kHz, SF 11, Low data rate optimize on
                1 = (normal for SSDV)       Implicit mode, Error coding 4:5, Bandwidth 20.8kHz,  SF 6, Low data rate optimize off
                2 = (normal for repeater)   Explicit mode, Error coding 4:8, Bandwidth 62.5kHz,  SF 8, Low data rate optimize off
                3 = (normal for fast SSDV)  Explicit mode, Error coding 4:6, Bandwidth 250kHz,   SF 7, Low data rate optimize off

SF_<n>=<Spreading Factor>  e.g. SF_0=7

Bandwidth_<n>=<Bandwidth>.  e.g. Bandwidth_0=41K7.  Options are 7K8, 10K4, 15K6, 20K8, 31K25, 41K7, 62K5, 125K, 250K, 500K

Implicit_<n>=<Y/N>.  e.g. Implicit_0=Y

Coding_<n>=<error_coding>.  e.g. Coding_0=5 (4:5)

To run, just type

sudo ./gateway

and you will see a screen like this:


In this example, channel 0 (the LoRa module in position 1 on the board) is enabled, at 434.451MHz, and mode 0 which is a shorthand for a mode suitable for continuous long-range telemetry transmission.

The status display updates as packets are received:


Finally, to exit the program, press CTRL+C.

Posted in Weather Balloon | 3 Comments

Pi In The Sky Board for Pi A+/B+

Here (at last – sorry for the delays) is our new version of our Pi In The Sky Board, designed for the Raspberry Pi models A+ and B+.

pits+-1000 These new Pi models required a few changes:

  • New smaller form-factor
  • Connector to fit the new, larger, GPIO pin header
  • Mounting points in all 4 corners
  • New higher capacity switch-mode PSU

We opted for a stackable GPIO connector, so that the board can be used in conjunction with some add-on boards that we are developing (see below for some details).  Unlike the model A and B, the “+” versions cannot be powered solely from 3.3V so we no longer use the trick of connecting 3.3V to the 5V rail, but instead simply supply 5V as normal.  The total run time is therefore slightly shorter than before, but not much as the Pi PSU is itself more efficient than on the previous boards.

pits+-1000-2 The board is on sale now at the HAB Supplies store.  Software is available on Github and is only slightly modified from that used by the previous board (and the same software works with either).  Support is available here. Now, those add-on boards.  These are not yet in production, as we need them to get a few flights under their belts so we know that they’re reliable.  First is the LoRa (Long Range Radio) board:

IMG_1214 I have flown LoRa trackers a few times now, with some very good results.  The above board has yet to fly but that will happen soon.  LoRa promises some advantages over the traditional RTTY system, with probably similar range at low speeds but with the option of higher download speeds and the possibility of an uplink (e.g. to request that the payload detaches from the balloon).  If you wish to experiment with LoRa I have uploaded both tracker and gateway software for the Pi to the above Github account, plus Arduino tracker software to my personal account. Here’s the prototype LoRa board attached to a model B+ with the PITS+ underneath.


Our other prototype is an APRS add-on for PITS+.  APRS is useful in countries which (unlike the UK) allow the transmission of amateur radio signals from airborne transmitters.  APRS is particularly prevalent in the USA where it is used much more than the UKHAS RTTY standard used by the PITS+ board.  If you want to try APRS with a Pi, using your own hardware, you can download our code from github (not flight-tested).

IMG_1215 This particular board has a 144.8MHz transmitter (European standard) but we expect most customers to opt for the 144.39MHz (North America) version. Here’s a tracker-from-hell, with the PITS+, LoRa and APRS boards stacked (and yes, the PITS+ PSU has ample capacity for this configuration!)

IMG_1216 I’ll blog here about flights using these boards as they happen. Now, some general advice on High Altitude Ballooning.  Much of this is copied from a previous blog post, but I’m repeating it here (and emphasising a few points) because a lack of proper preparation will almost certainly result in the loss of your flight.  Do not, as one recent launcher did, rely on blind luck to get your payload back; test everything and especially test that you can track the flight yourself.  Do not try to rush things, and do not leave preparation until 2 days before your flight.  If you do, you will very likely lose your flight, and will deserve to do so. Although it’s possible to successfully fly and retrieve a balloon with a simple GSM/GPS tracker, the chances are that this will end in failure and tears.  GSM coverage in the UK is nowhere near 100% especially in rural areas which is where we want (and aim) the flights to land.  The next step up, in reliability and price, is a “Spot” tracker which works solely via satellites, but those don’t work if they land upside down.  Also, neither of these solutions will tell you how high the flight got, or record any science data (e.g. temperature, pressure), or indeed tell you anything about the flight until they land.  If you’re lucky.  A lost flight is a sad thing indeed.

Still-1 For some countries (e.g. USA, but not the UK), if you are a licensed amateur radio operator you can fly an APRS tracker, in which case the flight will be tracked for you via the ground-based APRS network run by other radio hams.  Sadly UK laws prohibit radio hams transmitting from an airborne vehicle, so APRS is out for us. For these reasons, pretty much everyone involved in the hobby in the UK, and many other countries, uses radio trackers operating in an ISM (Industrial. Scientific and Medical) band where airborne usage is allowed.  These work throughout the flight, transmitting GPS co-ordinates plus temperature and anything else that you can add a sensor for.  Many radio trackers can also send down live images, meaning that you can see what your flight is seeing without having to wait for it to land.  Here’s a diagram showing how telemetry from the flight ends up as a balloon icon on a Google map:

system What’s not shown here is that, provided you tell them, the other balloonists will help track for you.  So not only will you be receiving telemetry and images directly via your own radio receiver, but others will do to.  All received data is collated on a server so if you do lose contact with the flight briefly then it doesn’t matter.  However, this does not mean you can leave the tracking up to others!  You’ll need to receive at the launch site (you have to make sure it’s working!) and also in the chase car once it lands.  The expense of doing this is small – a TV dongle for £12 or so will do it, with a £15 aerial and a laptop, ideally with a 3G dongle or tethered to a phone. Traditionally, balloonists build their own radio trackers, and for anyone with the skills or the time and ability to learn programming and some digital electronics, this is definitely the most rewarding route to take.  Imagine receiving pictures of the Earth from 30km up, using a piece of kit that you designed and built and programmed!  So if you are up to this challenge (and I suspect that most people reading are) then I recommend that you do just that.  It takes a while, but during the development you’ll have plenty of time to research other aspects of the hobby (how to predict the flight path, and obtain permission, and fill the balloon, etc.).  And when you’re done, you can hold in your hand something that is all your own work and has, to all intents and purposes, been to space.

Burst-1-1024x571 For some though, it’s just not practical to develop a new tracker.  Or you might be a programming whizz, but not know which end of a soldering iron to pick up.  It was with these people in mind that we (myself and Anthony Stirk – another high altitude balloonist) developed our “Pi In The Sky” telemetry boards.  Our principle aim is to enable schools to launch balloon flights with radio trackers, without having to develop the hardware and software first.  It is also our hope that older children and students will write their own software or at least modify the provided (open source) software, perhaps connecting and writing code for extra sensors (the board has an i2c connection for add-ons). The board and software are based on what I’ve been flying since my first “Pi In The Sky “flight over 2 years ago, so the technology has been very well proven (over 20 flights and no losses other than deliberate ones!).  It comes in a kit complete with a GPS antenna, SMA pigtail (from which you can easily make your own radio aerial), stand-offs for a rigid mounting to the Pi board, and battery connectors.  Software is on https://github.com/piinthesky, with installation instructions at http://www.pi-in-the-sky.com/index.php?id=support, or there is a pre-built SD card image for the tragically lazy.  We do recommend manual installation as you’ll learn a lot. By now you’re probably itching to buy a board and go fly it next weekend.  Please don’t.  Well, buy the board by all means, but from the moment you decide that this is the project for you, you should task yourself with finding out all you can about how to make your flight a safe success.  For a start, this means learning about applying for flight permission (which, if you want to launch from your garden at the end of an airport runway, isn’t going to be given).  Permission is provided together with a NOTAM (NOtice To AirMen) which tells said pilots what/where/when your launch will be, so they can take a different path.  You also need to learn about predicting the flight path so that it lands well away from towns or cities or motorways or airports.  I hope I don’t need to explain how important all of this is. There’s lots more to learn about too, for example:

  • How to track the flight – remember you MUST NOT rely on others to track it for you – you HAVE to be able to track the flight yourself both at launch (to confirm it’s all working) and after landing (so you can find it).
  • How to fill a balloon
  • Where to buy the balloon
  • What size balloon?  What size parachute?  How to tie it all together?

None of this is complicated (it’s not, ahem “rocket science”), but there is a lot to know.  Don’t be surprised if the time between “I’ll do it!” and “Wow, I did it!” is measured in months.  Several of them.  In fact, worry if it’s less than that – this research takes time, as does practice in tracking.  If at all possible, practice your tracking skills by tracking someone else’s flight before your own.  At a minimum, send a friend off, with tracker in hand, to play “hide and seek” after which you then go and locate him using nothing your tracking setup.  He should be at least half a mile away perhaps further.  If you cannot find your friend then you’re not going to be able to find a balloon payload either! We will be producing some teaching materials, but meantime please see the following links:

As for the board, it provides a number of features borne out of a large number of successful flights:

  • Efficient built-in power regulator providing run time of over 20 hours from 4 AA cells (using a model A Pi)
  • Highly sensitive UBlox GPS receiver approved for altitudes up to 50km
  • Temperature compensated, license-free (Europe) frequency agile, 434MHz radio transmitter
  • Temperature sensor
  • Battery voltage monitoring
  • Sockets for external i2c devices, analog input, external temperature sensor
  • Allows use of Raspberry Pi camera
  • Mounting holes and spacers for a solid connection to the Pi

The open-source software provides these features:

  • Radio telemetry with GPS and sensor data using UKHAS standard
  • Radio image download using SSDV standard
  • Multi-threaded to maximize use of the radio bandwidth
  • Variable image size according to altitude
  • Stores full-definition images as well as smaller transmitted images
  • Automatically chooses better images for download
  • Configurable via text file in the Windows-visible partition of the SD card
  • Supplied as github repository with instructions, or SD card image


Posted in Weather Balloon | Leave a comment

Commercial Launches

Videos from some of my commercial launches:

Superman (for RS and Mattel)


Space Potato (for Heston Blumenthal, Channel 4)


Dress Stratos (for Wreck My Dress)


BBC Cracking The Code



Posted in Weather Balloon | Leave a comment