Paper Plane, Battery Drain And Then Ukraine

This was a pretty successful flight though it didn’t quite go to plan!

It was a joint project with Anthony Stirk who has written it up here. The aim was to drop a paper plane over the North Sea, with that landing in Holland whilst the main payload continued on. Originally we were going to drop a second plane later on in the flight, but decided against that. The main payload (the one doing the dropping) was a Raspberry Pi with a Pi Camera, running via a switching regulator from 6 Lithium AA cells. It also had a small MOSFET board driving 3 resistive cutdowns – one for the first pane, one for the absent second plane, and one to drop the Pi itself to descend under a parachute. The Pi was programmed to trigger the cutdowns at longitudes of 4, 15 and 20, with the aim of having all 3 payloads landing inside our tracker network and thus potentially recoverable. The cutdown procedure started by switching the camera to video mode, then sending approx 8W into the cutdown resistor for a period of 8 seconds.

The day started with Anthony cutting and folding his paper planes from a sheet of thick A2 paper in the statutory Fuchsia Pink. It was a neat design incorporating a little cockpit for the radio tracker:


Meanwhile we figured out a way of mounting it on the main payload so it wouldn’t snag, then I set about putting that payload together.

At the launch site, there was initially very little wind, but as soon as I needed to measure the neck lift the wind picked up and didn’t let go until after the launch! It took what seemed like ages to get any sort of accurate neck lift measurement, and that was a bit over target but not enough to prevent the balloon from floating. At this time of year, and particularly with the current winds, it’s nigh on impossible to have a HAB flight launch from and land in the UK, so a better option is to go for a “floater” where the balloon runs out of lift somewhere between 30 and 40km altitude, instead of going up till it bursts. For the size and make of balloon we were using (a 1600g Hwoyee), if you aim for an ascent rate of 4m/s or less then it’s going to float instead of burst. We aimed for 2m/s to make sure! Here’s the wind shortly before launch:


We had to be patient, but eventually the wind dropped enough for a fairly straightforward launch. Back at the car I wasn’t getting any reception from CLOUDY (the main payload) but that was because I hadn’t got an aerial plugged into my receiver! Anthony’s SNOW (the plane) was working fine but his experimental backup tracker (WANNAB1), which was hanging just below the balloon, wasn’t being received. He suspects a shorted aerial.

The flight path followed the prediction very closely, heading north-east before turning east over Bury St Edmunds. The ascent rate was pretty close to target too, just a bit over because of the overfill. We then helped Leo Bodnar with his 2 launches, before returning to my house to watch progress.

Images from the Pi were reasonable, but because of the side-mounted plane the camera was pointing downward, meaning that none of the shots quite showed the horizon. Also, because of the late launch, it hit sunset earlier than planned. Nevertheless it returned some decent images including this one (fixed by Steve Smith G0TDJ for some missing packets)


CLOUDY was programmed to drop SNOW over the North Sea, at a longitude of 4.0, and we watched with tense anticipation as that longitude was reached. To our great relief we soon saw SNOW descending, and it soon became clear that it was actually flying – the descent rate was near that expected for a parachute, and the GPS positions showed that it was repeatedly stalling and then flying again. Here’s the flight path showing the separation over the North Sea:


and, thanks to Anthony, some Google Earth paths for the separation:


The acceleration and deceleration of SNOW are clear to see on that second image.

Meanwhile, CLOUDY continued onward and upwards. With the paper plane gone, the camera had a more horizontal view and by chance was pointing towards the setting sun, taking some great shots including this was with Venus clearly visible:


CLOUDY then achieved the desired float, at about 34km:


By then it was in the expected very strong winds, reaching speeds of up to 330kph (205mph), so it soon crossed the Netherlands and into Germany, touching the Czech Republic before entering Poland. By then it was further south than expected and heading South East instead of East, so we had fewer listeners in range than we’d hoped, but still coverage was pretty good.

The second cutdown triggered at longitude of 15, as programmed, though of course there was no second plane to drop. However this is where things went wrong – the cold batteries couldn’t supply the cutdown current, and the Pi reset. Of course when it restarted, and regained GPS lock, the cutdown program hit the cutdown again (actually the first cutdown), and it rebooted again. At this point I knew the flight was doomed to a cycle of rebooting, so after a while of watching it do just that I switched off the PC to watch the telly.

It might have been a clue when Mission Impossible came on. Once I got bored with that, I decided to quickly check the live map before retiring to bed, and was rather surprised to see that CLOUDY had managed to get past the boot-cutdown-reboot cycle. That cycle includes up to 3 cutdowns each time (2 for the planes and one for the Pi itself), and as the Pi was still floating it was clear that the final cutdown hadn’t managed to sever the line holding the Pi up. So although I was very pleased it had got so far, I knew that it wasn’t going to come down anytime soon and that the batteries (which would only last 20 hours even without the battering from the repeated cutdown cycles) would die soon. Which they did, with Pi approaching Kirovohrad in Ukraine:


Most likely the flight continued at least till sunrise, and probably burst soon after that, landing in or near the Caspian Sea.

So, an interesting flight, with some things learnt and things to do (some tests on very cold batteries and high currents, and a more reliable cutdown system for such flights).

Thanks go to Anthony of course, Leo Bodnar for helping out, Phil Heron for providing the SSDV software, the CUSF guys for the tracker, Steve for the edited SSDV image, and everyone who tracked the flights for us.

Footnote: CLOUDY was named after our cat Cloudy who has been missing for 6 weeks. It seems unlikely now that we’ll see him again, but a flicker of hope remains.


Posted in Weather Balloon | 9 Comments

Pi To Poland

Tomorrow (Saturday 28th December) I will be joined by Anthony Stirk to launch a Raspberry Pi “floater” which is expected to fly over the continent, over Holland, Germany and Poland, and probably beyond.

The high-altitude winds this time of year are strong, and we’re expecting speeds of 200mph (320kph) or more, meaning that it won’t take long for the flight to travel across the continent. This prediction shows about 9 hours of the flight!:


As usual the Pi will transmit live images but we’ll be heavily dependent on trackers in Holland, Germany and Poland to receive them.

Just to add to the fun, the flight will carry 3 other payloads and the Pi is programmed to perform 3 “cutdowns” during the flight, so some payloads will drop from the flight before the balloon bursts.

As usual, you can follow the flight live online:

On the map, the 4 payloads will appear as CLOUDY, RAIN, SLEET and WANNAB1.


The flight is a 1600g Hwoyee with a float profile to catch the extremely fast winds to Europe. The balloon will carry a small tracker called WANNAB1 doing DominoEX. Below this will be a a Pi doing SSDV (Callsign CLOUDY). Along for the ride with CLOUDY will be SLEET and SNOW which are paper planes with trackers.

As dropping stuff from balloons with no parachute isn’t permitted over the UK we have decided that somewhere over the North Sea / Netherlands SLEET and SNOW will detach and make their own way down to earth. They may make land fall in the Netherlands. The planes are snub nose delta planes with very small trackers in the nose – see the prototype. Both are powered by AAA’s and should run for 24 hours if anyone wants to go after them.

The CLOUDY and WANNAB1 will continue onward over Germany hopefully entering a float around 36km, as they enter Poland CLOUDY will detach from the balloon and come down under a parachute. Again you’re welcome to go after it, battery life on this will be limited. The plane drop videos will be on the SD card but we don’t expect to get this back.

Finally WANNAB1 will continue onward under the balloon.

Tracking Details:

$$SLEET 434.400 RTTY 50 7N2
$$SNOW 434.410 RTTY 100 7N2
$$WANNAB1 434.420 DominoEX16
$$CLOUDY 434.200 RTTY 300 Baud SSDV

As there are so many flights on Saturday please review the info page/

We’d all appreciate it if you could organise yourselves so there are trackers on all the payloads in the air. I suspect given the wind speeds our trackers in the Netherlands and Poland are going to be key. stream from the launch site here :

and Dave cam here :

Happy tracking!

Anthony & Dave

Posted in Weather Balloon | 2 Comments

Driving a scrolling LED badge from a Raspberry Pi

For a while I’ve wanted to build a “Flight Readiness” unit that I can have near me when filling a balloon, and will show me if the tracker is running OK or if there’s a problem with the tracker or receiver (e.g. it may have drifted out of tune). To build this I needed a WiFi-connected computer (a Raspberry Pi is an obvious choice) plus a display that is easily visible in a variety of lighting conditions. I opted for an “LED badge” which is a small scrolling message board, purchased on ebay for £13 (about $20).


These displays typically have a USB socket for charging and programming, and appear to a PC or Pi as a virtual serial port. They come with Windows drivers and software to download messages to the device, the intention being that you download your message then unplug and run the display from its internal battery. Messages are stored internally in flash memory so the device can be powered off and it will retain the message.

For my purposes, I want to be able to send a message from a Pi, and have the device display that message (scrolling if necessary) until I replace the message with another one. I can then get the Pi to display the current tracker status – e.g. “All OK”, or “No GPS Lock”, etc.

So the first job was to get the device running on my Windows PC. The device installed as a serial device (the common Prolific PL2303 driver) and the supplied software successfully sent messages to it:


So with the software working, the next job was to have a look at what it was sending to the device. For this I downloaded a serial monitor program from HHD Software. This is an excellent program and runs for 14 days in trial mode with nag screens. For the above message and settings it showed this packet being sent, at 1200 baud:


Perhaps surprisingly, the “hello world” text doesn’t appear. In fact, this is because the PC is rendering the text and sending it as a 1-bit bitmap pattern. By sending different messages with different parameters (brightness, scroll speed, direction and “loop” which is a marquee effect) I gleaned the following about the protocol:

  • The first item is a 6-byte startup packet “Ahello”
  • This must be followed by a short delay (10ms works well)
  • The next 48 bytes contain the message parameters and the number of bitmap packets.
  • This must be followed by a delay of at least 800ms
  • The bitmap packets follow, 11 bytes each, with a delay of at least 100ms separating each from the next.

The parameter section can be adjusted as follows:

  • Byte 0 (the first byte of the parameter packet) has the brightness in bits 2-0.  Value 0 is the brightest and 3 the dimmest.
  • Byte 2 has the following:
    • Bit 7 is set for the marquee effect
    • Bits 6-4 contain the speed from 0 (slow) to 7 (fast)
    • Bits 2-0 contain the direction (0 is “move to left”)
  • Byte 14 contains the number of bitmap packets.  For some strange reason, this value is repeated in bytes 16, 18, 20, 22, 24, 26 and 28.

The bitmap packets are 11 bytes each.  The first byte of the first such packet represents the first 8 dots starting at the top-left of the image being sent, with a “1″ representing a lit LED.  Bit 7 in that byte is the top-left dot, and bit 6 is the one to its right, etc.  The next byte in the packet is for the next 8 dots to the right of the first 8, assuming the image is wider than 8 bytes.  in other words, the image is scanned one row at a time from top to bottom, and is sent in 11-byte packets.  The smallest possible image then would consist of 1 bitmap packet, representing 11 rows (the display is 11 rows high) of 8 dots each.

So, with the protocol understood, I needed to port this functionality to Linux on the Raspberry Pi.  I investigated some Linux programs that can render text as suitable binary dot patterns, such as the strangely named “toilet” program, but the resulting images weren’t as easy to read as ones generated from the Windows program.  So, I opted for a 2-stage approach; I wrote a Delphi Windows program to build a nice clear character set and then copied the result into a C program on the Pi that can use it to render text before sending it to the display.  To make the job slightly easier, I had the Delphi program generate actual C source code, like so:

struct TCharacter
    char Character;
    int Width;
    int Pattern[11];

struct TCharacterSet
    int Count;
    struct TCharacter Characters[95];
} CharacterSet = {95,
                  ' ', 4, 0x000, 0x000, 0x000, 0x000, 0x000, 0x000, 0x000, 0x000, 0x000, 0x000, 0x000,
                  '!', 4, 0x000, 0x000, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x000, 0x004, 0x000,
                  '"', 3, 0x000, 0x002, 0x002, 0x002, 0x000, 0x000, 0x000, 0x000, 0x000, 0x000, 0x000,
                  '#', 9, 0x000, 0x000, 0x050, 0x050, 0x0FC, 0x028, 0x028, 0x07E, 0x014, 0x014, 0x000,
                  '$', 7, 0x000, 0x008, 0x008, 0x03C, 0x00A, 0x00A, 0x01C, 0x028, 0x028, 0x01E, 0x008,

I put this in a .h file and included it in a new program that:

  • Accepts command-line parameters to set the scroll speed etc.
  • Renders text using the above character set information
  • Sends the header packet, parameter packet, and bitmap packets to the LED badge at 1200 baud and with the appropriate delays as above.

Initially I did this with the badge connected to the Pi’s USB port.  The badge appears as /dev/ttyUSB0 and it’s a simple task to open that port, set the baud rate, switch off output processing (we’re sending binary data so we don’t want CR/LF conversions etc!) and to send the data.  However, this particular badge only displays the message once, and then switches to “charge mode” where it dims the display and shows a battery charge graphic; it only shows the message continuously when unplugged from USB!  This behaviour is not useful for any application that wants to update the message and then display it for a while before changing the message.

So, I took the display apart to see what I could find:


Unsurprisingly, there’s a Prolific USB-serial converter, with the serial Rx and Tx pins connecting to Tx and Rx on the LPC1113 ARM Cortex-Mo processor.  There’s also a Microchip LiPo charge controller, and of course a large matrix of SMD LEDs.

The first thing I wanted to do was bypass the USB interface, since it’s ugly to have a large USB plug sticking out the side of a fairly small display.  Pin 1 on the PL2303 is the Tx pin that sends data to the CPU, so I carefully lifted that pin with a scalpel and soldering iron.  Conveniently, the track goes to a relatively large pad labelled “Rx” so I soldered a wire to that for connection to the serial Tx line on the Pi GPIO header.  With this and a GND wire connected I could happily program the badge from the Pi.  Finally, I connected 5V from the Pi to the 5V USB line on the badge (the pad for a missing D4 component was ideal for this).

However, there was a problem.  As mentioned earlier, the badge’s firmware “knows” whether the device is externally powered or not.  It does this by taking the USB 5V line, passing it through a potential divider to drop to about 3V, and then takes that to a digital input pin on the ARM processor.  The firmware then does one of the following 2 things, both undesirable, depending on the state of that pin:

  • High (USB connected) – Displays the message once, then enters charge mode
  • Low (Disconnected) – Resets, displaying a startup logo, then displays the message continuously

So the second scenario is better, but means that every time the Pi changes the message, there’s a delay whilst the startup logo is shown.  However, a combination of the above would be good – pretend that USB is connected so the message appears quickly and then, before it stops scrolling and enters charge mode, pretend that USB is disconnected.

To do this, I removed the potential divider and connected the ARM’s input pin directly to a GPIO pin on the Pi.  Here’s the modified board with all 4 wires (5V, 0V, Serial Data, GPIO) connected:


The required sequence is then:

  1. Raise that pin high
  2. Send the message
  3. Wait a moment for the message to appear
  4. Drop that pin low

I used the Wiring Pi GPIO program to test this, and I’ll soon integrate the pin control into my program with the WiringPi library.

Here’s a short video showing the badge in operation, with the Pi updating the message:

And finally, here’s the badge mounted on a Pi case with an RS USB Power Bank:


Posted in Raspberry Pi, Weather Balloon | 8 Comments

HAB-o-Cam – Raspberry Pi Video Streaming to

I usually run a video stream from my launches, using webcam attached to a laptop or more recently with my Chase Car Pi, so that people following the flight can see what’s going on. Following a suggestion by Anthony Stirk, I decided to set up a second streaming camera which I can strap to my chest for a close-up view of the launch preparations.

For this to work, I needed to get the whole thing (Pi, WiFi, PiCam, battery pack) packaged up to survive the odd knock. This meant internal batteries and that in turn meant the use of rechargeables (so I don’t have to unscrew the case to replace them). I ran some tests and found that regular 4 AA NiMh cells would run the Pi/WiFi/camera for plenty enough time. I then tried to fit the batteries into a case and that only worked without a battery holder. Even so, I had to remove almost all the connectors from the Pi to make it all fit. I opted for a Cyntech Blackberry Raspberry Pi Case as this had enough internal space and is of a soft enough plastic to work with (cutting holes and slots for the camera and power switch).


Into the case went 4 2650mAh Ni-Mh cells, an MSP1825S regulator, 100uF cap, power switch and a Pi Cam:


All a bit of a tight squeeze! The back of the case I screwed to a GoPro mount, to fit to a GoPro chest strap:


The camera pokes through a small square hole cut in the front of the case. Here you can also see the power switch and WiFi adapter:


Operation of the device is very very simple: switch it on. It automatically starts a simple script that pipes the output of raspivid through ffmpeg and thence to the batc server.

Finally, here I am modelling the entire setup:


Posted in Raspberry Pi, Weather Balloon | 5 Comments

Raspberry Pi & Pint Talk

Last night I went into London to meet up with other Pi enthusiasts over a pint, and to do a talk about my Pi-based weather balloon activities. Thanks to Andy and Matt for organising it and inviting me! Here’s a pic from Andy of me in “action”:


The talk seemed to go down well and as requested I’ve shared my slide-show which you can view here.

A few people asked me about how to get involved in the hobby. Even if you don’t fly your own balloon you can have a lot of fun helping other people by tracking their flights. All you need is a suitable radio aerial and receiver, and you can find out all about how to do this on the UKHAS wiki which is a triumph of content over organisation, but the first link you need is to the Tracking Guide. You don’t even need an expensive receiver, as a simple SDR (aka TV USB Dongle) will do as explained here. To get the best range (so you can receive flights across the UK) you need to get an aerial (cheap or make one yourself) up high, and preferably add a HAB Amp specially designed for the task.

The HAB (High Altitude Ballooning) community is small but very friendly and active, and almost everyone in it hangs out in the #highaltitude IRC channel. To ask questions, or see what we’re all talking about, use an IRC client (I use Hex-Chat) or connect via the web client. I’m on there as “daveake” but you’ll find plenty of other friendly people there too.

Finally, flights are (usually) announced on the mailing list first, telling you when the launch is planned to be (weather and technical issues often have a say in that), what frequency etc. To track a flight, join the list first and when you see a flight you want to track, join the IRC channel and check that it’s still going ahead. People there will be pleased to help if you have any trouble setting up. Even if you don’t help track, you can watch the action on the map and that will usually have links to any extras such as live images or video streaming from the launch site.

Posted in Raspberry Pi, Weather Balloon | 2 Comments

Update – Chase Car Raspberry Pi with GPS, Video Streaming

Following my previous post, I’ve now packaged up my Pi Chase Car system, using the new Raspberry Pi GPS Board from HAB Supplies.

The original GPS receiver, purchased on ebay, just wasn’t up to the task of getting a good GPS signal inside a Raspberry Pi case.  The HAB Supplies board has an SMA socket for use with an external GPS antenna which can then be placed in a suitable position in or on (using a magmount antenna) the chase car.  For a car especially, where the sky is partially blocked by the roof (and perhaps by a heat-reflective windscreen) this is a much better arrangement.

The board has a couple of other nice features.  Firstly there’s a backup battery (supplied) so the receiver will regain lock very quickly after power-up.  Secondly, all of the GPIO pins are connected to two rows of holes on the board, making it easy to connect to LEDs, switches or anything else.  For my chase car computer, I wanted to connect 2 switches to enable or disable a couple of functions, so this was ideal.  Here’s the board connected to a model A:



The yellow/black wires connect to two small and very neat rocker switches bought from Maplin for 99p each. I fitted one into each half of a Cyntech Blackberry Raspberry Pi Case, by cutting (carefully, with a sharp scalpel) the RJ45 aperture (not needed of course as this is a model A Pi). No doubt other cases are just as suitable though ones made from harder plastic will require cutting with a Dremel or similar rather than a knife. This case is nice as it includes an SD card cover – essential for use in a car where the card could get knocked, breaking the card and/or holder. After cutting I glued the switches in place, firstly with some super-glue to get them into position, and then with some hot melt to secure them further. Here’s the outside of the case showing the switches, plus the WLAN adapter and the GPS cable coming out of the case where the model B’s double USB socket would have been:


One switch controls the position uploads to, whilst the other controls streaming to

Lastly, I mounted the Pi camera on the case using a Pimoroni Camera Mount, used upside-down to normal. I’ve yet to install everything in my chase car, and when do I may have to move the camera for a better view, so a permanent fixture can wait.

P1080911External connections to the box are a standard micro-USB car power adapter, and of course the 4.3″ foldaway LCD screen showing the basic car and balloon information needed on a chase:



Posted in Raspberry Pi, Weather Balloon | Leave a comment

Chase Car Raspberry Pi Computer

Chasing balloons across the country is one of the best, and probably the most exciting, parts of high altitude ballooning, using a car kitted out with aerials, radios and at least one computer to decode the radio transmissions from the balloon and show the balloon on a map. I have a PC (home-built using a mini-ITX motherboard and a touch-screen monitor) to do this, but many of the functions could be done more simply, and more reliably, and for a *lot* less power consumption, on a Raspberry Pi. So I set out to build a Pi-based computer with these features:

  • Run from car 12V battery
  • Upload position of chase car to the map at
  • Stream video from the car to
  • Show basic balloon telemetry
  • Show a compass pointing to the balloon, with distance from car to balloon


To do this I needed:

  • Model A Raspberry Pi
  • UBlox GPS receiver
  • Miniature monitor
  • Pi Camera
  • Pi Case
  • 12V Micro USB adapter
  • 2 small switches
  • Wifi Adapter

My car has a MiFi device and the Pi connects to that by WiFi.


There are many tiny monitors available that are sold on ebay and elsewhere as “rear view screens” for cars.  They run on 12V at low power, and have a composite video input which the Pi can drive directly.  They usally have 2 such inputs so you could also use them with a rear-view camera for example.  I bought a 4.3″ folding model which is slightly better resolution than the smaller ones:


Just supply 12V power (only about 150mA needed), connect the Pi and power that up (for a car just use a good car Micro USB adapter).  You may need to adjust the “overscan” settings to centre and size the picture correctly.


This is needed so the Pi knows where it is, so it can upload the car position and so it can calculate where the balloon is relative to the car.  I used a UBlox module but for this application any GPS receiver with a “TTL Level” serial output will do.  Connect to the GND, 3.3V and serial Rx pins on the GPIO connector.



The Pi Camera is the obvious choice, as it is cheap, good quality and has very very low CPU overhead.




I split the task into several programs which share a block of memory that contains the GPS and balloon data.  The programs are:

  • gps.c – Reads the GPS data and stores the important data (latitude, longitude etc.)
  • balloon.c – Reads the balloon telemetry by connecting to dl-fldigi (running on my car PC – as yet we don’t have a Pi-based solution for that)
  • chase.c – Uploads the car position to
  • batc – bash shell script that uses ffmpeg and raspivid to stream video to
  • lcd.c – Reads the GPS and balloon data and displays the results on the monitor using the OpenVG C library

Both batc and chase.c read switches connected to the GPIO ports to enable/disable the batc streaming and chase car upload.

batc Streaming

Streaming works really well with the Pi camera – much smoother than when I did this before using a webcam.



I can stop and start the streaming using a switch.  This is tested using a small shell script which starts or kills ffmpeg and raspivid accordingly.  The status of the switch is shown on the LCD.

Chase Car Upload

This is pretty easy to do, using the GPS data read elsewhere.  The result is that the car position is always visible on (assuming an internet connection):


I can stop and start the upload using a switch, which is read by the chase.c program.  The status of the switch is shown on the LCD.


At present the LCD simply shows a “direction-finding” screen.  This is probably the most useful screen when chasing, as it tells you the direction to drive in and how far to go.  It’s certainly easier to use something like this when driving than a full map.

monThe compass shows the direction to the balloon, calculated from the positions of the balloon and car, and relative to the direction that the car is headed.  The small circles show:

  • H – Green if HAB data being received
  • G – Green if GPS data being received
  • C – Green if chase car data being uploaded to
  • B – Green if video being streamed to

I’ve yet to package this up and install in the chase car, but that’s next.


Posted in Raspberry Pi, Weather Balloon | 2 Comments

LOHAN Test Flight

I and the rest of The Register’s LOHAN team will be doing a test flight this Monday about 2pm local time. There will be a total of 4 trackers, one sending SSDV images, plus a batc video stream from the ground.

Launch site is about 150km west of Madrid. We would REALLY appreciate help tracking this one, so if you happen to be within range of the flight, or know anyone who is, or know how to contact Spanish/Portuguese radio hams, please do!!

All trackers will be sending telemetry via USB RTTY. The tracker IDs and frequencies will be:

CHAV on 434.075MHz
BUZZ on 434.200MHz
ZURG on 434.250MHz
SPEARS on 434.650MHz

CHAV will be 300 baud 8 data bits, no parity, 2 stop bits, and will be sending SSDV packets as well as telemetry.

All the others will be 50 baud, 7 data bits, 2 stop bits

CHAV images will go to

BATC stream at

If you can help but haven’t tracked before, please read The UKHAS Tracking Guide for instructions. Anyone in Spain, Portugal or SW France should be in range for some of the flight at least.


Posted in Weather Balloon | Leave a comment

Bear-Bones Computer Beats Red Bull Stratos

I’m delighted to report that, on the second attempt, Babbage the Bionic Bear was successfully dropped from just over 39,000 metres, with a video of the “jump” taken by the capsule camera, and with both payloads recovered. So all of the main mission objectives were achieved!

The first attempt was with Eben and Liz from the Raspberry Pi Foundation, fellow balloonist Anthony Stirk, and John Jackson from Radiometrix. Both Babbage and the capsule carried the new NTX2B radio transmitter from Radiometrix, and this was the first time they’d been flown under a weather balloon. Unlike the older NTX2 model which is only available in 2 frequencies, the NTX2B is factory-programmable across a wide range. With the number of amateur weather balloon flights these days this will be a great help in reducing frequency conflicts.

This launch was probably the most difficult I’ve done, with strong blustery winds that just wouldn’t let up, as you can see in this photo

(c) Liz Upton

(c) Liz Upton

and video of the preparation

The flight itself went fairly well, with Babbage apparently trying to make his escape early


but when it came time for him to actually jump, at 39km, nothing happened. Instead both capsule and bear continued upwards eventually peaking at an impressive 41,109 metres (well above the calculated burst altitude of 39.5km), breaking the record for “highest amateur image transmissions”, before having a soft landing in a field


and then being reunited with “parents” Liz and Eben


Once I got Babbage back home, I started looking into what had gone wrong. The cut-down software creates a log file and this showed that it had triggered correctly at 39km. Next I checked the cut-down circuit and that was connected and working normally. The only item left was the cut-down resistor, which is supposed to get hot enough to melt a nylon cord holding Babbage up. I tested this with the worn batteries from the flight, and it did melt nylon but not very quickly. I’d opted for small batteries in order to keep the weight down and give me the best chance of breaking 39km, but in doing so I compromised the power sent to that resistor. So knowing that the flight got to over 41km, I felt confident that I could increase the weight (thus reducing the burst altitude), meaning I could use more batteries, and larger ones, and drop the resistance, all of which mean more POWWWEERRR. Finally, I decided to bring the resistor inside the payload to stop it getting too cold, so it didn’t need to heat up so much. Predictions were looking good for the Monday, so I scheduled a second launch for then.

Monday was a much better day to launch – very little wind, rather warmer, and skies were clearer meaning better photos. Sadly Liz, Eben, Anthony and John couldn’t make it, but we did have the company of Greg and his team who launched their own flight before us. Here I am putting the back on the capsule:


The launch itself was very easy

and we soon set off in chase, briefly stopping near where Greg’s flight had landed so we could get a position for him. This time, and to my great relief, Babbage was released as scheduled when the GPS reached 39km, thus beating Felix’s altitude record (but not his skydive or speed records!) by 31 metres:

The capsule kept rising, this time up to exactly 41,000 metres when the balloon burst. About this time we saw that Babbage didn’t switch back to taking images, and this was because his SD card was dislodged when (I think) his parachute deployed. The result was that the video he took of his leap was truncated, and he didn’t take any images of his descent. However he did continue to send telemetry back to the ground.

By this time we’d stopped for petrol, near Shaftsebury in Dorset which is roughly where we expected him to land.


As we watched, the car 3G cut out as the SIM card ran out of credit! All the computers and tablets in the car run from a MiFi device which shares the 3G signal over WiFi, and I had to topup the card before we could continue! Fortunately I did that before Babbage landed (he was coming down quite slowly as his parachute was a tad larger than necessary) and we managed to upload his position before he disappeared at an altitude of about 500m. We then set off in pursuit, picking up his radio signal as we got closer. We could get within 50 metres or so by road, but there was no obvious route to get to him from there, so we backed up and parked near to the gate to the field. Here you can see where he landed and the path we took back towards the car:

Ted Recovery


With Babbage safely back in my hands, it was time to set off back to where the capsule had landed. This was another easy recovery, about 100 metres from a road:


So, both payloads recovered, and a video of Babbage breaking that record – here in its entirety and sandwiched between time-lapse videos of the ascent and descent

Thanks go to Philip Heron for providing the SSDV image software, the CUSF guys for the tracker and prediction software, Anthony and John for coming down for the launch, Liz and Eben for bringing the Raspberry Pi to us and for helping out on that first launch, and of course my wife Julie for helping out on yet another mad project.

Media Links


The Independent




The Register

The Telegraph



Letter to The Times

The Irish Independent

BBC Click Radio

The Daily Orbit – Video

Southgate ARC

Seven Sharp TV in New Zealand (love this one)

Geek Insider

Posted in Raspberry Pi, Weather Balloon | 6 Comments

Babbage Flight

Babbage will be launched this Saturday morning between 10:30am and 11am, from Berkshire. Landing prediction is SW of Newbury.

The flight is a single balloon with 2 payloads, each one transmitting SSDV (images) and telemetry.

The main payload is called PIE. This has a cutdown mechanism that will release the second payload (TED) at 39km or when it senses a burst. Obviously 39km isn’t guaranteed even though the payloads are both relatively lightweight (less than 400g total) and the balloon is a 1600g Hwoyee filled with H2. 39km is 31 metres over Felix Baumgartner’s jump altitude, in case you wondered why it was chosen!

Both trackers are model A Pi boards each with UBlox GPS, NTX2 transmitter, Pi Camera module. TED’s camera is where his right eye used to be, and will look outwards for a normal view. PIE’s camera is directly above TED, looking down. So for most of the flight it will mostly see the top of TED’s head.

Flight Plan

Both payloads change what they do with their cameras depending on altitude. At low altitude (<2km) the transmitted images are small (320x240) and above that larger images (512x384). Also, both are programmed to take a short video of when Babbage is released. Depending on timing between the camera side and the transmission side, there may be a short period when no image is transmitted while the camera is recording video.

Additionally, full resolution 5MP images will be taken and stored when above 2km.

PIE is set to release TED as soon as it detects an altitude of 39000m or greater. This check is done on every new reading from the GPS and triggers a MOSFET-driven resistor cutdown, which should release TED after 2 seconds or so.


To configure dl-fldigi just choose BABBAGE in the drop-down list, choose TED or PIE (makes no difference as they have the same settings) then hit autoconfigure. Or do it manually: Carrier shift 600Hz, 600 baud, 8 bits, 2 stop bits. Nominal frequencies are 434.200MHz (TED) and 434.250MHz (PIE).

To view the images as they come in, choose View ? SSDV in the menu. You don’t need to do anything else different to normal. You will see the binary image data coming in between telemetry strings, but of course it will just look like garbage. So long as you see the lime-green “Successfully decoded image packet” window then all is good. Telemetry is interlaced with the SSDV packets so you’ll see that coming in too.


Live streams from launch site and chase car: and

All SSDV images: (or you can select either payload with or

Tracking on as usual

Posted in Weather Balloon | 37 Comments