Birthday Balloon

This was my second test flight of my 868MHz LoRa fast SSDV (Slow Scan Digital Video) software, to celebrate my 58th flight and 56th birthday.


I made some changes to fix some issues with the previous test flight:

  • Set RTTY baud rate to 300 to prevent RTTY Tx during LoRa Rx period
  • New MTX2 programming code
  • Replace the UBX GPS code with NMEA code

The RTTY overrun was due to accidentally leaving the tracker at to 50 baud after a brief test.  The timing had been set using 300 baud RTTY (ensuring that the RTTY sentence had finished before the LoRa uplink slot), so when set to 50 baud the RTTY was still sending when the tracker was trying to listen on the LoRa frequency.  Although the frequencies are very different, this still slightly deafened the LoRa receiver and meant that only 12 messages were uploaded during that flight.

When the Pi starts up, the MTX2 radio transmitter is programmed to the configured frequency, and this process failed under some circumstances (depending on Pi operating system version and PITS version).  This was resolved and extensively tested.

During the previous flight, the payload went silent for long periods (1 minute or more) a few times, as the new GPS UBX code failed to get an updated time and position.  I traced this to some very slow responses to UBX requests via I2C, but didn’t have time to resolve the issue so I reverted to tried and tested NMEA code instead.


I also made some changes to the SSDV code, storing telemetry in the JPEG file comment field, by using the EXIV2 program.  This information is then available (via EXIV2) to the image processing script which can then overlay the downloaded image with on-screen text and/or graphics.  I added such a script using ImageMagick for the rendering.


I re-used the same payload as my previous test flight – a Pi A+, PITS+, LoRa board with single 868MHz module, Pi camera and 4 (fresh!) AA batteries.

The 868MHz antenna was below the payload with a 434MHz stubby antenna above (not an ideal position, but usable, and avoids compromising the 868MHz antenna).

Total weight including 18″ Spherachute and cord is less than 250g.  Ascent rate was targetted at 4.5m/s with an expected burst altitude of 31-32km using a 350g Hwoyee balloon filled with hydrogen.


The launch was easy enough, with very little wind (good, as I was alone).  There was some thick and fairly low cloud cover, and once through that the payload mostly sent some fairly boring images of nothing but blue sky and white cloud.  After a while though it was high enough to see some better weather and so we started to see some better images:

Note the overlay with telemetry along the bottom (altitude, latitude, longitude and UTC time), plus an altitude graphic with the balloon on a translucent background.

As the flight approached peak altitude, the pictures improved markedly, with this probably being the best one.  For comparison, I’ve inserted a live image from my very first Pi flight, at the same scale in pixels.  Roughly, the new image has 10 times the number of pixels, and took about 1/10th of the time to transmit.

For this flight there were 2 other gateways set up by other HAB enthusiasts, as well as my too.  Even with this limited coverage we still lost very, very few packets.  I had my Python script running to check for missing packets, and creating uplink messages to request repeats of those packets.  Throughout the flight 35 such messages were uplinked to the flight, which is 3 times more than last time, but still I noticed that the uplink stopped working before the downlink stopped, so this is something to try and improve for next time.

With 3-4 gateways running we again saw an issue with SSDV uploads timing out.  I’d seen this before when running 3 gateways at my location, and assumed my internet connection was the cause, but now we were seeing the same thing with 3 gateways at 3 different locations.  Phil Heron checked the server and saw that it was, at times, struggling to keep up, so that’s something to look at for next time.

The balloon burst at an altitude of over 32km, and produced this image during descent (note, no missing packets which is impressive for the first image during descent):


Since the flight was mainly about testing the radio side, I stayed at home checking the radio communications, aiming and swapping aerials, until the flight had descended beyond my range.  I then prepared the chase car and checked the final descent positions and landing predictions.  The landing area was just south of Avebury, near Cherhill White Horse, and about 1 mile from the nearest road.  From the Ordnance Survey mapping I could see that the area was hilly and that unless the payload happened to land on top of a hill then I was unlikely to receive a signal from the road.  I made sure to pack walking boots, backpack and mobile tracking gear as this wasn’t going to be a quick and easy recovery!

The landing area was about 90 minutes drive from home, and when I got there I set up a rooftop aerial and drove along the nearest road hoping to hear a signal from the payload.  Nothing.  As expected the area was hilly and I could see a bridleway up to a monument at the top of a hill, so I parked up, packed my backpack, and walked up the hill with the radio on, listening for the payload.

As I got near the top, I had a choice of taking the path up to the monument, or a short walk across a field to a ridge overlooking the valley the other side of the hill.  That sounded like a better (easier!) bet, especially as I thought the payload would be in that valley.  Sure enough, as I got closer, the radio burst into life with that familiar RTTY sound.  I sat down to get the laptop set up, and the signal almost disappeared – it really made a huge difference how high the aerial was.  So, with laptop and radio on the ground, I held the aerial up to get a decoded position.

Unsurprisingly then, the payload position turned out to be in the valley below:


I then had a choice of a direct route down a very steep hill (see those contour lines!) or a more leisurely, slightly longer and rather safer walk across the ridge and down a more gentle slope:


On the way I caught my first glimpse of the payload below (parachute on left; payload on right):


So in the end, not a difficult recovery if we ignore the steep climbs!

For more photos, click this image:


Posted in Weather Balloon | Leave a comment

Fast HAB Imaging

It’s now quite common for high altitude balloon flights to send down live images during the flight, as well as the usual telemetry.  However data rates from balloons are rather low, so each image can take several minutes to send even for rather low resolutions.

"It's currently a problem of access to gigabits through punybaud"

Maximum data rates are a function of several things – emitted power, receiver sensitivity, path loss, aerial gain, duty cycle (proportion of time that the transmitter is active), bandwidth (amount of the radio spectrum used by the signal) and the type of modulation – and these items have legal and practical limits.

For UK flights we use licence-exempt radio transmitters and so operate within the limits defined by IR2030,  For almost all flights, operators choose the band from 434.04-434.79MHz, because this range allows for continuous transmission (100% duty cycle) and is shared with the amateur radio 70cm band, meaning that receiving equipment is readily available.  Maximum power in this band is 10mW e.r.p. (effective radiated power), and the modulation scheme most often used is RTTY.  To allow reception by ham radios, the modulation has to fit within a frequency range that those radios will pass, which is about 4kHz.  Historically radio transmitters drift in frequency considerably, so if the modulation uses a large proportion of this bandwidth then receivers will need to re-tune almost continuously.  With this, and the increased packet loss at higher baud rates, 600 baud is a practical limit for transmission speeds with RTTY, and most flights with live imaging settle for 300 baud.  With modern temperature-compensated radio transmitters this could probably be pushed to 1200 baud with fair success.

LoRa Modulation

Anyone who follows this blog will be aware that I’ve been experimenting with LoRa modules, which use their own (patented, sadly) modulation scheme.  However LoRa modules are cheap and work well, so until something else comes along that is as good and open-source, then I’ll continue flying them.

LoRa chips offer bandwidths up to 250kHz, which is way beyond the practical limit with most ham radio receivers and indeed beyond that allowed in the 434MHz band that I mentioned.  Higher bandwidths can allow for higher throughput, though the receiver will then see more noise (as it has a wider frequency range to listen to) so the signal-to-noise ratio is worsened, meaning that range is compromised.

Some bands around 434MHz do allow for wider bandwidths, but only at limited duty cycles of 10% or less.  There’s not much point in using a bandwidth 10 times wider if you can only transmit for 10% of the time, as the throughput is back where you started!  However there’s a section of the 868MHz range that allows for both high bandwidth (300kHz) and continuous operation.  The downside (there is always a downside) is that transmitted power is even lower, at 5mW ERP.

LoRa devices operating within the 434MHz band mentioned above can use up to 20.8kHz bandwidth, giving a data rate equivalent to about 1400 baud RTTY.  Going from 20.8KHz to 250kHz gives nearly 17,000 baud equivalent.  This is still pathetically slow compared with 3G or home broadband, but it’s much, much faster than the 300 baud that we’re used to.  If, of course, it works.

Need For Speed

Higher data rates mean that, for example, instead of taking 5 minutes for a low resolution (about 600 x 300 pixels) image, we can send a 1280×640 image in about 70 seconds.  Here’s an example image being transferred with a bandwidth of 250kHz:

Packet Loss

As discussed, wideband modulation reduces the SNR seen by the receiver, so range is limited compared to narrowband modulation.  The lower tranmission power (5mW vs 10mW) makes SNR a little worse, as does the path loss of 868MHz vs 434MHz.  The end result will be increased packets loss as the signal level drops, through the balloon payload swinging around and as it gets further away.

We can mitigate these factors somewhat by using a Yagi aerial at the receiver and a filtered pre-amplifier.  Even so, and with error correction in the image packets, some packets will be lost resulting in blocks missing from the received images.  What can we do if that happens?

Play It Again

Another nice feature of LoRa modules is that they are transceivers, so we have the option of sending messages back up to the payload from the ground.  So, why not have a ground station take note of any missing packets, and then send a message to the payload asking for those packets to be sent again?  All we need is a way of spotting missing packets, and a scheme (e.g. TDM) that provides an uplink slot where the payload stops transmitting and starts listening for a short time.

It’s not difficult for a listening station (LoRa gateway) to build a list of missing image packets – it just needs to take note of which packets have been received.  However there may be several listening stations – this is a key feature of the UKHAS listening network – and there’s no point asking for a packet to be re-sent if it was already received by another station.  So, this logic needs to be done centrally.  With this in mind I spoke to Philip Heron who invented the SSDV (Slow Scan Digital Video) standard, wrote the encoding and decoding software that converts between JPEG and SSDV, and wrote the code on the SSDV server that accepts packets from listening stations and combines them into JPEG files which it displays on web pages.  Philip very kindly wrote a web API for the server, providing functions which a LoRa gateway can use to produce a list of missing image packets.

I had already written code in my LoRa gateway to produce this list locally, so I removed most of that code and instead created some new code that queries the SSDV server and produces a list of missing packets for the latest 2 SSDV images, for a particular payload.  I chose 2 because if the payload has recently started transmitting a new image, we need to know if it has to go back and re-transmit any missing packets from the previous image.

Test flight will happen when the weather is a bit better!

Posted in Weather Balloon | Leave a comment

Portable LoRa Gateway

This is a packaged version of my LoRa gateway, for use when chasing high altitude balloons.  Based a a Pi V2 and official Pi screen, it currently features:

  • Receipt and upload of LoRa telemetry messages to
  • Receipt and upload of LoRa SSDV imagery to
  • Local storage of telemetry log and SSDV images
  • Chase car position upload to
  • LCARS (Star Trek) user interface with display of balloon position and images
  • WiFi connection to internet (e.g. via MiFi or mobile phone WiFi hotspot)
  • Approx 24 hours of run time from powerbank

Future plans include display of balloon position on a map, and navigation to the balloon position include voice guidance.


The parts are all readily available:

  • Raspberry Pi V2 (B+ or A+ will also work, but the extra speed is useful)
  • Raspberry Pi touchscreen display
  • Hofbauer XtraBag 200 Case, Black
  • LoRa board for the Pi
  • Powerbank
  • 2 Micro USB cables
  • Double-sided tape
  • Door trim
  • SMA plug-socket cable
  • 70cm aerial

There are instructions here for building and installing the LoRa gateway.  I will post again shortly with instructions on installing the LCARS interface.

I used a Dremel with cutting tool to cut a hole in the case, then stuck the display down with double-sided tape.  A length of rubber door insulation was then cut and placed around the display to provide some protection.  The powerbank was held down with Velcro, and connected to the Pi and display using short micro USB cables.  Finally, a short SMA cable was used so that aerials can be connected externally.


The Pi is set up to auto-start the LoRa gateway and LCARS program.  These two programs talk via a socket so that the LCARS UI can display the current payload position:


Posted in Weather Balloon | 1 Comment

Astro Pi Flight – Update

I’ve made some progress on my “tweet uplink” software, and now all stages in the process are fully automated except for a required manual approval step, in case anyone tries to spam the flight!

The key new element is a Windows program that lists incoming tweets and offers Accept and Reject options for each tweet that mentions a particular hashtag, for example:


The tweets are received via a simple Python script using the tweepy library, which saves each as a separate file which the Windows program then sees and displays:


Each accepted tweet is then moved to an accepted list (the tweet file is renamed from <Twitter ID>.tweet to <Twitter ID>.accepted):


The next step is a bit more complex.  To make the most of the available radio bandwidth, tweets are combined together into radio packets.  So whenever there are enough tweets to combine, or the uplink queue is empty, the program seeks to find the best combination of tweets to join together into a single radio packet (max 255 bytes).  These packets are then placed in a queue on a Raspberry Pi running my LoRa gateway:


Here we just have a single tweet, because only one was generated in the above example.

Periodically, the balloon tracker stops transmitting down to the ground, and starts listening for an uplink from the gateway.  If the queue has at least one entry then the gateway program will send one entry to the balloon.  In turn, the balloon tracker will receive the packet and save it as a file.  Meanwhile, a small Python script will see that file and start displaying it on the Astro Pi LED.

The gateway needs to know if the uplink was received OK or not, so the tracker includes a “last message ID received” value in the telemetry packets that it sends to the ground:


The gateway then parses this information and removes the matching message from the queue (renames <ID>.sms as <ID>.ack).  The final step is for the Windows program to then remove the message from its list of queued messages and add it to the list of acknowledged messages:


Posted in Weather Balloon | Leave a comment

Tweeting Above The Clouds

Following my recent successful test of balloon-to-balloon communications, I had the idea of uploading messages from the ground to a balloon (via LoRa radio), and then have those messages displayed on the LED matrix of an “Astro Pi” Sense HAT, as will be used by Tim Peake during his stay on the International Space Station.

You may well be asking who is likely to see those messages, so here’s the plan:

  • Launch a weather balloon before Tim flies to the ISS on Soyuz TMA-19M
  • Encourage people to send messages to Tim Peake via tweets to a specific hashtag
  • Those tweets will be automatically uploaded to the balloon via a radio link
  • Tweets will then be scrolled on the Astro Pi LED matrix
  • A video camera which will record the entire flight and the scrolling messages
  • Download sense HAT data during the flight
  • After the flight is recovered, selected camera footage will be uploaded to YouTube and sent to Tim.

There’s nothing particularly complicated in the above, but there are quite a few steps involved to make it work.

Astro Pi + Pi In The Sky + LoRa Board

For the balloon tracker to perform the above tasks, it needs an Astro Pi of course, plus a Pi In The Sky board for GPS and power, plus a LoRa board to allow for uploads from the ground.  The first thing to do then was check to see if there are any I/O conflicts between the above.

The only conflicts were to do with one of the 2 LoRa modules on the LoRa board.  Since we only need 1 LoRa module, we can just put that in the non-conflicting position (CE1).

So, I built a stack with a Pi B+ on the bottom, then a Pi In The Sky (PITS) board, LoRa board and finally an Astro Pi board which, of course, has to be on top otherwise the LED matrix won’t be visible!


Reading Tweets

The first part of the sequence is to search Twitter for messages to upload, and for this Iwrite a short Python script using the Tweepy library.  The following function and main code show the process:

def SearchHashtag(HashTag, LastID, Count):
  c = tweepy.Cursor(, since_id=LastID, q=HashTag).items(Count)
  for tweet in c:
    text = tweet.text.encode('ascii',errors='ignore').decode("utf-8")
    print(str( + " - @" + tweet.user.screen_name + ": " + text)
    if > LastID:
      LastID =
  return LastID

 LastID = 0
 Count = 10
 HashTag = '#AstroPiTest'
 while 1:
   LastID = SearchHashtag(HashTag, LastID, Count)
   print ("LastID = ", LastID)

The complete script reads each matching tweet:


and creates a separate text file for each such tweet:

@daveake: Just testing for a project ....

For the actual flight then will be more filtering, both programmatic and human, to ensure that only real/polite/sane messages are uplinked!


For the radio uplink I have modified my LoRa Gateway, which is normally tasked with receiving LoRa transmissions from balloons and then uploading the data (telemetry and/or images) to a web server.  For this flight though we need it to be able to send messages up to the balloon.  That’s a straightforward task, using GPS timing to decide when the balloon can transmit and the gateway should listen, and then when the gateway can transmit and the balloon should listen.  For testing I’ve set a short period each minute for the uploads, but this may change for the flight (to allow more messages to be uploaded).

The gateway has to monitor a folder, looking for messages to upload.  Those messages are produced by the Python script mentioned earlier, so the gateway just has to read the messages, and send them to the balloon.  Sometimes tweets may come in faster than they can be uploaded, so the code will need to be able to cope with that.

Here’s a screenshot of the gateway uploading the above message:


Receiving Messages At The Tracker

For this I modified the PITS software so that it can accept and process these uplinked messages.  To keep the PITS changes simple, all it does is receive the message:


and then create a small file containing the text to display:

Just testing for a project ....


Displaying The Message

This is done by a simple Python script that uses the Astro Pi library.  The following snippet shows how it works:

def process_file(file):
  print ("File found: ", file)
  f = open(file, 'rt')
  line =

  sense = SenseHat()
while 1:
  for file in os.listdir('.'):
    if fnmatch.fnmatch(file, '*.sms'):


The Result



Posted in Weather Balloon | Leave a comment

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.  The eventual aim for this is to fly a series of balloons across Europe, with data passing from balloon to balloon, thus considerably extending the radio range which would otherwise be limited by the Earth’s curvature:


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) to reduce 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 of 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 it is 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 flights.

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

Next up was LORA2 under a 350g balloon.  Very impressively, this was received by Phil’s gateway when at just over 1.1km altitude, which is rather below his 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.

I then checked my LCARS LoRa receiver, which was happily showing the position of both airborne trackers as well as LORA3 (still on the bench):


Finally, I launched LORA3, again under a 350g balloon.  The planned burst altitude for this one was about 28.5km but, as sometimes Chinese latex completely ignores specifications and goes rather higher.  Usually that’s just an extra 2km or so, but this time it was 10km higher than calculated!


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 Phil’s gateway, 82% of LORA1’s packets were received directly, and 58% were received indirectly via LORA2.

LORA1 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 (LORA3 for example was lost at 998m).  Of course this time we also had 2 mobile repeater stations in the form of LORA2 and LORA2, in good position to relay LORA1’s telemetry.  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.

UPDATE 1: LORA2 now recovered.  The payload was exactly where the GPS reported (see satellite image above), with the line/chute/balloon dangling down to about head height.  Thanks to helpful people at the site it was recovered in minutes.

UPDATE 2: LORA1 now recovered.  I received a phone call several weeks after the flight, from the landowner who found the payload in a field.  I think a sheep must have been holding it hostage when I looked for it, as the aerial had obviously been chewed!

Posted in Weather Balloon | 1 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  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  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, will show live and historic data from your station:



Posted in Weather Balloon | 3 Comments

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