Category: Technical

Below is a thank-you video…to all the people who helped make the mission a success.

This is not how it ends….the adventure has only JUST begun…..

In this post is a graph of internal and external temperature (all in Kelvin) against time. The graph we see is very much expected and we are fortunate it was like this as the batteries would not have worked terribly well if it dropped too much.

The external temperature reading themselves aren’t what I’d expect. Temperatures go down below zero in some parts of the atmosphere. I put this down to the fact the temperature sensor is mostly enclosed in some Areldite (glue) to reduce chance of shorting of leads in ‘wet’ environment. We are also going very quickly through the various zones of the atmosphere which means we might not have enough time for the temperature to settle.

What is interesting is the lag between internal temperature and external temperature. The Internal temperature was recorded inside a Polycarbonate box, which inside was generating some heat itself – majority from the RFD900 radio and other electrical components.

Overall, the flight went exceedingly well. Over the course of the next few weeks, we will go through some of results/measurements.

We sum up in this Post what went well and what didn’t go so well.

Quick Analysis

• The radio communications link went well between the groundstation and the payload. At no time did we lose communications, except when the payload descended below the hill to its landing spot. The temperature of the payload box also remained at a healthy temperature and the radio modem temperature in the payload did not get very hot as was expected! Which was surprising.
• The photo stills taken by the Linksprite lived up to our expectations. We got about 20 photos. While the colour in them doesn’t seem as “rich” as one would expect, I’m still very happy with the. We were able to download two of them with no issues during the flight.
• The temperature sensors didn’t drop down to the cold temperature I was expecting. Perhaps this is because the temperature sensor was partially encased in Areldite glue to stop short-circuiting if there was any moisture. Not too sure.
• The tracking software worked, but there were TOO many GPS data points and the text at each data point overlapped other points. This I think slowed down the Beaglebone Black which made it almost impossible to ‘zoom’ in and view the way points of the flight. Some method of thinning them out is required…and a different method/approach of showing GPS information at each way point. Perhaps something like the Spot Messenger public facing page.
• The GPS worked well, right up to 28.1km! This is fantastic. The original GPS module we had in the payload was one that could only work up to 18km. So it was great that this new GPS (which is supposed to work up to 50km) did work so well.
• The “approximate” altitude calculation (based on air pressure) seemed to be way off! It is possible that this was outputting in feet (not metres) and hence the inflated approximate altitude values.
• The Video camera using the HackHD was very disappointing. I _had_ noticed some issue with very over-exposure (too bright/white) during some testing, but failed to resolve this. As a result, most of the flight video was extremely white. It appears HackHD does not have an AutoWhite balance control.
• The deployment/launch of the balloon was a stunning success. Everyone knew what they had to do and there were no problems with the cylinder.
• Because the balloon was recovered a week after the launch and the onboard siren battery only lasts 27hrs, we could not depend upon this to assist with recovery. We are thinking of having one that is on for 30 seconds then off for 5 minutes, then on again..etc. This could extend the battery life significantly and make recovery a LOT easier.
• The last code update to allow the ground controller to disable/enable picture download was a fantastic feature that helped significantly. We would have had a lot less photos taken (because the payload would have spent more time sending photos and not taking them). This control also enabled us to focus on the tracking as opposed to the photos side, which is not as important.

From these observations, we will determine what improvements can be made for future flights (should we conduct future missions).

 

 

 

 

More pictures taken aboard the payload are below:-

We performed the Balloon Launch today!

Unfortunately, we haven’t been able to recover it because it is so far off the “beaten” track. However, it has been a stunning success. We were able to track it the entire launch, except when it dropped below 1115 metres (behind a hill). Our Spot Messenger worked well. It has given us the final landing spot.

We managed to collect a lot of data and downloaded two pictures. See these pictures below:-

First one is at approx 5000m, the second is at approx 23,000m. Notice the moon in the second photo?

We aim to hike out to the landing spot next weekend and recover the payload.

(More info on successful launch later…)

 

We have had a NOTAM created, so we have completed all steps to ensure we comply with the launch.

For those interested, the NOTAM is:-

GG YSCBNOFE
300144 YBBBZEZX
C1584/14 NOTAMN
Q) YBBB/QWLLW/IV/M/W/000/999/
A) YBBB
B) 1410312000 C) 1411070700
E) UNMANNED BALLOON LAUNCH WILL TAKE PLACE BRG 151 MAG 16NM FM CHILLAGOE (YCGO) AD PSN S17 22.8 E144 39.8
F) SFC G) UNL

Continual Improvement

Even as we draw closer to the launch date, we are continually making refinements to the launch procedures and devices to mitigate possible risks. Some of the risks have been identified and listed below:-

1. One risk is that our balloon pops and that we are then left with no chance of performing our mission.
2. Another risk is that the inflation tube bursts
3. Another is that the file downloads causes problems (incomplete) and causes temporary loss of communication.

We have addressed (1) by contacting BOC and asking if we can take a spare cylinder. We can, and we are able to return it for a Credit if not used. (Thanks Cairns BOC! Really appreciate this).

We have addressed (2) by purchasing spare tubing and superglue so we can manufacture another one.

We have addressed (3) by providing another button on the web interface which the operator can use to disable picture downloads.

The Day of the Flight

We are putting a bit more thought into how the day will progress. The exact details of how the launch will be conducted are still something that will evolve over time and become clearer once we have a predicted flight plan. Like any problem, we are going to split the flight into several stages. Most likely something like this:-

 

FROM (Min)	TO (Min)	Notes
0	15	Observing – seeing how close to predicted path and speed, etc. Will then confirm path.
15	35	Driving approx 30km (or distance determined)
35	55	Observing – get gps co-ordinates + photo (if can) + health status
55	75	Driving approx 20km
75	85	Observing…till balloon pops (Should be approx 83rd minute) – Will first disable photos.
85	100	Driving approx 15km
100	111	Observing decent till out of range. (flight length approx 1hr 51mins).

Software

We have released software used to manage the flight. It is downloadable from GITHUB:-

Software for the groundstation (runs on Beaglebone Black running Debian)

https://github.com/joeman155/JJTEAM_GS.git

 

Software for Arduino

https://github.com/joeman155/JJTEAM_HAB.git

 

X-modem library required by JJTEAM_HAB

https://github.com/joeman155/JJTEAM_XMODEM.git

 

 

The Balloon can in some cases travel quite far distances and so tracking the balloon needs to be as easy as possible. Much useful data, like GPS co-ordinates, speed and direction are already gathered. We also calculate and display the distance between the ground station and the payload. A graphical representation of the trek of the balloon and the position of the groundstation – a map – would be most helpful. This post describes the steps to accomplish this.

OpenStreetMap (http://wiki.openstreetmap.org/wiki/OpenStreetView)  is a very good “free” mapping software that can be installed on a LINUX based system. First we needed to assess this piece of software and its suitability. It was initially installed on a Debian machine using a map that encompasses a fairly large area of the Cairns region, where all balloon trajectories are within. Initial testing suggested it should meet the requirements – it was highly functional and showed the main roads that would be traveled and the API DEV interface is well documented.

The installation process was replicated on a Beaglebone Black. Angstrom Linux was ditched in favour of Debian Linux. Additional space was required, so an 8GB microSD was inserted, formatted and mounted. I had to go through the whole slow process of compiling support for the RTC_DS3232 module and get wireless etc going. Because a lot of additional packages were required, many unrequired packages had to be removed.

The result, a map that can be viewed offline and show all the waypoints of the balloon and the position of the groundstation when using a phone/pad device with built-in GPS. Below is a screenshot of it.

 

Here is an example with predicted flight path in red.

The interface has been written to show only way points for the current day. Red way points are for the balloon, except for the Green one which is the beginning one. A Blue point indicates the vehicle (when we have a GPS enabled device, e.g. an iPhone). Red path is the predicted flight path and can be generated by uploading a CSV file created on http://habhub.org/predict.

NOTE: We don’t have the blue icon here because this was done from a browser without a GPS device.

A line separates each balloon way-point and time/position are recorded against each way-point.

It can be a little slow at times, but when a map is generated and cached, when it is later recalled, things work relatively quickly. Definitely suitable for what we need it to do.

It has been a while since the last post, so I thought it would be a good idea to provide an update in the progress of the project.

• The application for flight is still with CASA/AirServices.

• Some good progress has been made in regards to Spot/Gimbal mechanism. A gimbal contraption has been constructed almost completely out of PVC pipe to allow the Spot Messenger to be orientated correctly (upwards), regardless of the orientation of the payload.

Since the project has changed quite a bit, I’ve decided to do up a short video of the payload systems. Please find below.