BallastHalo 5

BallastHalo 5 is the most recent payload in a series of launches to test ballast tank concepts in anticipation of a trans-atlantic balloon launch. A successful trans-atlantic launch would require the ability to drop ballast at night to counteract the loss of helium from the ZP balloon during the day.

The first 2 launches of the series tested whether it was possible to get a latex balloon to float by adding a small pinhole vent to the bottom of the balloon; Ballasthalo 2 managed to float for over 7 hours. After that work began on the ballast tanks, the initial approach was to use high quality, low power solenoid valves and a sensor to detect the volume of ballast remaining, this however did not work and instead a peristaltic pump was integrated. Peristaltic pumps are able to pump a know volume with each turn and so by counting the turns it is possible to calculate how much has been pumped. This design was flown on Ballasthalo 3 and BallastHalo 4, during the Ballasthalo 3 flight the secondary flight computer crashed so the pump was never activated. During the Ballasthalo 4 flight the activation of the pump resulted in the loss of GPS fix and due to the way the code was written there was no way to turn off the pump and so no proper data was received until the pumps batteries ran out. Once the GPS fix resumed it was found that the pump had pumped over 4000ml.

BallastHalo 5 aims to build upon these problems and demonstrate the pump working at altitude. Once the balloon begins to float the dropping of ballast will break this float which will be easily seen with an increase in ascent rate.

1. Properly test ballast tanks, demonstrate a change in ascent rate after dropping ballast (not necessarily during a float but will be more obvious.)
2. Float the balloon rather then a normal up/down flight
3. Recruit multiple users of dl-fldigi in anticipation of a trans-atlantic flight

As BH4 has been recovered it would be sensible to reuse the payload, there are a number of fixes that are required and a redesign of the polystyrene container to make it more streamline and less heavy.

The main flight computer is a custom PCB with an ATmega328 running the arduino bootloader, also onboard is a 3.3V voltage regulator and an Radiometrix NTX2 434.075Mhz 10mW transmitter. The flight computer also connects to the FSA03 Ublox GPS module and controls the peristaltic pump. This is all powered by 4x AA Lithium Energizier batteries. The pump has its own power supply of 4x AA lithiums.

The main software loop reads the gps data and parses it, the data is then reformated into the UKHAS standard and transmitted by the radio as RTTY 50 baud, 350 shift, ASCII-8, no parity, 1.5 stop. This can be decoded by dl-fldigi and the strings are uploaded to our server to be plotted on a map. Within in this loop the ascent rate is calculated and if a float is detected then the ballast pump is activated and 100mls of ballast will be dropped. There are 4 modes:

1. if total_float_time is more then 600 (10mins) and we've still got ballast left
2. Emergency drop if we are descending
3. DJE Drop - because the payload is drifting too far
4. if the ascent rate is too slow

The volume of ballast dropped is measure by counting the number of rotations of the pump have occured. Rotations are measured by a photogate on an interrupt which increases a counter. Peristaltic pumps are very accurate, the pump on BH5 pumps 0.26mls per rotation.

On the flight train is a backup beacon which is a ATmega168 again running the arduino bootloader, with another NTX2 434.075Mhz which will be transmitting CW and Hellschreiber every 10 minutes, due to temperature drift this shouldn't interfere with the main transmission.

Pinhole vented balloons have been found to start floating when they experience sunset (theorised to be due to the sharp temperature change), sunset at altitude occurs approximately an hour after sunset on the ground. For this flight we plan to launch the balloon 3hrs before sunset so that at an ascent rate of between 2 and 3 m/s it has enough time to reach a suitable float altitude. Once the float has been detected the payload will drop 100mls of ballast which should result in a reduction in the mass of the payload and therefore an increase in free lift. This should break the float and show a noticeable rise in altitude, showing that the ballast tank system has worked!

Depending on the altitude we might regain float and if detected will drop ballast again. Very little information is known about floating balloons so it is difficult to predict what will happen!

CUSF Predictor - 07/07/10

• Backup Beacon = 90g
• Main Payload = 1100g
• Parachute = 25g
• Ballast = 450g
• Total = 1665g

1. New batteries into beacon
2. Turn beacon on
3. Check working
4. Seal beacon box
5. New batteries into main payload
6. Fill ballast tank
7. Turn on main payload
8. Flush ballast through
9. Check working
10. Check uploading to spacenear.us
11. Seal main payload, attach antenna.
12. Rig parachute, backup beacon and main payload
13. Start filling of balloon (taking into account mass of vent)
14. Insert vent into balloon neck
15. Attach main line to balloon
16. Final call to ATC
17. Final check telemetry is correct
    1. Decoding correctly
    2. Fields change with each transmission
    3. Uploading to map
18. Launch
19. Track in field until high enough for other stations to take over then move back to tracking station.

Any help will be welcomed.

• If you have a radio receiver that can do 70cm (430-440Mhz) and SSB and can link it up to a computer then you can help track the flight - as there is a high chance the payload won't come back we need to gather as much data as possible. The telemetry you receive can easily be uploaded to our server if you use dl-fldigi to decode the signals on your computer. To track the balloon please follow the guide on the UKHAS Wiki Tracking Guide.
  • Select 'atlas' in dl-fldigi
  • Main payload details: RTTY ASCII-8, 50 baud, 350shift, no parity, 1.5 stop bits
  • Backup details: CW (14WPM) and Feld-Hell (Hellschreiber)
• If you aren't able to use dl-fldigi but can still listen in then any signal reports will be very useful; of the CW, Hellschreiber and RTTY.
• There are a number of online radios that it might be possible to use, just loop back the sound output into dl-fldigi to decode (either using software such as SoundFlower on OS X or just a 3.5mm jack cable from audio out to audio in!)
• Get onto our discussion IRC channel on #highaltitude irc.freenode.net
• Follow the flight path http://spacenear.us/tracker/
• To be kept up to date with progress of the flight follow my twitter account http://twitter.com/jamescoxon
• For information on future flights join the UKHAS mailing list

• Fix GPS/Pump interference
  • Test current setup
  • Shielding?
  • Change code to allow for a non-lock situation
• Fix balloon vent - hot glue to make sure completely sealed
• Fix external temperature sensor
  • New DS18B20
  • Update code with 1-Wire address

The Falcom FSA03 is a recently avaliable GPS module based upon the excellent 50 channel Ublox 5 chipset with a helical antenna rather than a patch antenna. This GPS module is far superior to the lassen IQ, it is able to get and hold a lock far better and has much more protection from interference. This should make construction and testing far easier and should certainly help with the flight. The module can be purchased from Earthshine Designs for an excellent price considering how good the module is.

The module is really designed to be soldered onto a breakout board (such as Esawdust) however I'm far to impatient and so am going for the directly soldered on wires. All that is required is VCC, GND, and TX however I recommend also adding RX and the addition of a backup battery will improve fix times even more.

The Ublox 5 module has a number of modes, for use in balloons you need to change the mode to Airborne <1g as this will allow the GPS to go up to 50km altitude! To do this you'll need to use u-center to configure the module, your changes will only be maintained if you have added a backup battery as the fsa03 does not have a eeprom onboard.

As I'm on a Mac OSX I had to run u-center with Wine, I found that Wine 1.01 and u-center 5.07 worked well:

port install wine
wine u-center_5.07_Installer.exe
cd ~/.wine/drive_c/Program Files/u-blox/u-center
wine u-Center.exe

You'll also need to link the serial port to the dosdevice in the wine config so that u-center can find it:

ln -s /dev/ttyUSB0 ~/.wine/dosdevices/COM1 

(from Paparazzi Project)

However to insure that the the GPS is set to Airborne <1g we can get the flight computer to send the command to the GPS module on start up. Thanks to juxta of Project Horus for the code - more info can be found on the UKHAS wiki

// Send a byte array of UBX protocol to the GPS
void sendUBX(uint8_t *MSG, uint8_t len) {
  for(int i=0; i<len; i++) {
    Serial.print(MSG[i], BYTE);
  }
  Serial.println();
}

  // Set the navigation mode (Airborne, 1G)
  //Serial.print("Setting uBlox nav mode: ");
  uint8_t setNav[] = {0xB5, 0x62, 0x06, 0x24, 0x24, 0x00, 0xFF, 0xFF, 0x06, 0x03, 0x00, 0x00, 0x00, 0x00, 0x10, 0x27, 0x00, 0x00, 0x05, 0x00, 0xFA, 0x00, 0xFA, 0x00, 0x64, 0x00, 0x2C, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x16, 0xDC};
  sendUBX(setNav, sizeof(setNav)/sizeof(uint8_t));

Ublox 5 modules send out a lot of nmea strings, so many that they can overfill the serial buffer so after setting it to airborne mode we turn off all the sentences we don't need:

  //Turning off all GPS NMEA strings apart from GPGGA on the uBlox modules
  Serial.print("$PUBX,40,GLL,0,0,0,0*5C\r\n");
  Serial.print("$PUBX,40,ZDA,0,0,0,0*44\r\n");
  Serial.print("$PUBX,40,VTG,0,0,0,0*5E\r\n");
  Serial.print("$PUBX,40,GSV,0,0,0,0*59\r\n");
  Serial.print("$PUBX,40,GSA,0,0,0,0*4E\r\n");

As all the main components will be in the same payload bay for this flight I'm going to scrap repairing the 3rd temperature sensor and instead have an internal and an external temperature sensor, moving one of the original sensors outside. Am continuing to use the OneWire library for the Arduino. Occasionally a temperature sensor reports a reading of '0', this appears to be due to a timing issue when polling the data - as it works 99% of the time, not going to fix it!

The backup beacon is the same as was used on BallastHalo 4 and was key in the recovery of the payload. The hardware has remained the same with an ATmega168 and a NTX2 on 434.075Mhz but I have updated the software to transmit both CW (Morse Code) and a new format Hellschreiber. Using a single line from the ATmega to the radio keying on and off it is possible to 'draw' the character - basically each letter or number is regarded as a 7×5 grid which the receiver cycles through (from bottom to top) when it receives a signal it fills that pixel black, no signal and it stays white. So for an example using 0 as no signal and 1 as a signal the letter 'T' will be:

0000010 0000010 0111110 0000010 0000010

(the spaces of course would not be there - just to make it easier to read.) Hellschreiber can be decode by fldigi however currently it is not included in dl-fldigi but will be in the future. What makes Hellschreiber a good format is that it relies on the human brain to decode the characters, the computer just displays the pixels, a skill that we excel greatly at even when there is lots of interference.

Thank you all for helping out with the flight last night. While BallastHalo 5 has landed in the sea we got a lot of good data from the flight. Remember this payload has already visited France and the Netherlands so its worked well beyond its mission length so we can see this a seaside retirement.

After a very slow journey up to London we set about setting up our 'control centre' in Churchill and powered on the payload. The weather was hot and the wind had just started to pick up - the payload managed to get up to about 40deg internally while we waited for a GPS lock - this was achieved by taking the payload outside. The rest of the setup was simple and filling of the balloon didn't take long - because of the wind it was a challenge to work out neutral buoyancy however a combination of waiting for the wind to die down and running with the balloon worked. Once we had filled correctly we attached the payload string, walked out into the field at this point I found that the ballast tank had leaked about 10mls however just made sure all the tubing was attached correctly and then we launched. Visually the launch the initial ascent rate was nice and slow and other stations began to pick up the data at 300m or so. The payload weighed 1750g and we added another 250g of free lift aiming for an ascent rate of 2-3m/s.

After hurrying back indoors and linking up to the yagi tracking seemed to be working well being able to receive both the main payload and also the hellschreiber easily. The ascent rate rose a bit up to 3.5m/s then settled down to a nice 2.2m/s with the external and internal temperatures remaining surprisingly warm up until quite high. The balloon gradually rose with a very slow decrease in ascent rate to around 1.8m/s though it didn't drop below the 1.5m/s threshold for a small ballast drop (put in place to stop an underfilled flight going on for ever, this was set up to only occur between 500 and 15000m). The light sensor reported sunset ~ 1 hour after ground sunset and it was at this point that the balloon began to float - like in BallastHalo 2 there was an amazing rapid deceleration over about 5 minutes down to a stable neutral buoyancy. This was detected by the flight computer and after 10 minutes started to dump ballast however the pump rotation sensor (photogate) did not register the pump working so while we were observing a rise in temperature (pump working) and also a break in the float and rise in ascent rate the flight computer didn't detect this and continued to pump ballast. Eventually the sensor began to work and it detected enough rotations for it to decide it had dumped enough - however by this time we would have dumped all the ballast and we were rising up very rapidly. The float had been at 23km altitude so we had quite a large amount of altitude left to play with and while we began to notice a decrease in ascent rate it was still too fast and it reached its burst altitude and began to descend. As this point the flight computer recognised this and did an emergency ballast drop (though the tank was empty and it wouldn't have helped!).

Unfortunately for BallastHalo 5 to have avoided the sea it would have needed to float for about 2 hours, as we only floated for 19 minutes it was still quite far out to sea and splashed down.

We had some great tracking yesterday evening - the room we use in Churchill has excellent west and east views but terrible Northern views so we struggled to get data however the dl-fldigi/tracker system excelled with G4FEV rx'ing 901 strings, G3VZV 687 strings and M6LEP 644 strings. Lots of other people contributed and if you managed to rx a string and submit it pleased send me your postal address in a separate email and I will send out a Pegasus HAB Project QSL card. Also an enormous thank you to Alexei (natrium) and Rob (M0RJX) who did some rapid hacking to overcome my time stamp issue and tracked down the rogue data. Please not that there is no chase boat - it is just Alexei messing around!

Now on to the good things and the bad things. With a slow ascent rate launched to coincide with an altitude sunset at 20km altitude or so with a small vent in the balloon it will float - we replicated this with both BH2 and BH5 - this is something to explore as its a very interesting phenomenon - I'd like to launch a flight with out ballast just to see how far we could float it - something for the future. BallastHalo 5 was able to detect this float and triggered a ballast drop - the pump did seem to work with the noticeable rise in ascent rate and temperature even if the sensor failed. It therefore seems that a peristaltic pump is a good choice for ballast dumps. The sensor was strange, at first it didn't work (-27C) and then as the payload warmed up a little it began to work more(-22C) and then it worked properly(-19C) which would suggest something to do with temperature. A number of theories have been suggested including temperature related threshold or my construction techniques, this certainly needs some testing. Because we dumped all our ballast at once we didn't get enough float to make it back to land, this could have been avoided if the code had stopped the ballast drop once the ascent rate increased - again an oversight by me!

Overall it was a really fun launch - the community really helped out with the tracking, the listener system is a lot of fun and with flights like these its great that people interpret the data as it comes in. Finally a big thank you for Ed Moore and Steve Randall for the help with the flight preparation and launch.

Sure if it hadn't dumped all its ballast then it would have flown all night but then it would have probably landed in the Irish sea - this payload did great things, now its floating in the North Sea - with the remnants of a bottle of ethanol - its probably having a great time!

Thank you again to everyone who helped out.

• Pictures of the launch and payload can be found on flickr: http://www.flickr.com/photos/tags/ballasthalo5/
• Launch video: http://www.youtube.com/watch?v=TzsMS7RvChg

• Padding time
• Ballast Sensor
  • Test photogate
  • Hall sensor as well
• Better tank seal
• Better insulation on NTX2
• Code
  • stop ballast drop with altitude and sensor