On Monday the 8th of March we launched Horus 2 - the weather was very poor, and combined with other factors, this resulted in a less than satisfactory launch. Once we'd waited for a break in the wind & rain to let the balloon go, we realized that it was underfilled & didn't have the lift we'd wanted - the balloon was only ascending at 1m/s. With the high winds, the balloon was moving faster than we could keep up.
Within 45 minutes, we realized the balloon had stopped ascending (at around 1500m) & was coming down very slowly - and still racing away from us at 80km/h. Fortunately, thanks to those listening in & some contact via the local repeaters, we still had a good idea where it was and we kept chasing it - eventually recovering it in a tree with the balloon still inflated here.
It looks as though the polystyrene payload and parachute absorbed enough water in the rain to negate the small amount of lift provided by the balloon, and the payload slowly came down, where it was dragged along the ground by the wind for some time, until it wound up in a tree.
Given the balloon didn't reach the minimum altitude for the higher baud rates to kick in (5km), the launch was not a great success - though it was certainly a learning experience for us, and we wont be making the same mistakes next time.
I apologize to everybody who tuned in to help us track the payload or helped out in some other way for the rather disappointing launch.
I'm planning on re-launching the same payload soon with a few improvements - will keep the blog updated!
In other news, my boards have arrived from BatchPCB, and I've put together the first prototype of my Isis flight computer. Testing is looking very positive so far - the FSA03 Ublox 5 module is excellent.
If you are tracking the flight of Horus 2, you will need to configure dl-fldigi to change bit rate when the payload changes the transmission speed (see the previous post). As dl-fldigi does not automatically switch baud rates, this needs to be done manually - thankfully it's very easy!
To switch the baud rate, select Op mode -> RTTY -> Custom:
Once you've brough up this dialog, simply select the baud rate you'd like to switch to, then hit 'save' followed by 'close'.
To improve dl-fldigi's decoding performance, it's worth changing the interpolation in use. To do this, select Audio -> Settings whilst the dl-fldigi options dialogue is open. I suggest changing from the default linear interpolator to the fastest sinc interpolator - the medium & best sinc interpolators may perform better, but they have very heavy CPU requirements.
The weather is holding up & looking great for our launch tomorrow.
We're hoping to get the balloon in the air at about midday, launching from near Mt Barker. We're using a smaller balloon this time, so our overall altitude will not be as great - the balloon will burst around 18-20km.
This launch will mainly be to test higher baud rates - the payload will be switching baud rates as it gains altitude, the baud rate profile will be as follows:
- 0-5 km altitude: 50 baud
- 5-7 km altitude: 100 baud
- 7-9 km altitude: 150 baud
- 9-11 km altitude: 200 baud
- 11-13 km altitude: 300 baud
- 13+ km altitude: 50 baud
The payload will return to 50 baud for descent to give greatest tracking reliability.
The telemetry has been re-worked to use a stronger checksum (CRC16), which should help us with the higher baud rates we'll be testing during the flight.
I have just issued a NOTAM request for a launch on Monday the 8th of March - a public holiday here.
I'd like to use the flight to test higher speed telemetry, as well as stronger checksums & hopefully get the parachute working correctly this time.
The backup CW beacon will be aboard, as well as the arduino flight computer from Horus 1 - though I may modify this slightly, time allowing. I'm not planning any cameras this time, we'll be keeping weight to a minimum to use a smaller balloon and less helium. Given the smaller balloon, altitude will be lower - somewhere around the 20km mark - this is mainly a test flight.
More info soon!
I put together a simple backup CW (morse code) beacon for future launches yesterday for total cost of only a few dollars.
The beacon is comprised of only a microcontroller, a $4 10mW 434mhz transmitter & a few passives. The beacon is a standalone device, and pips out a few bits of information about the payload, including the frequency and transmission mode for the primary telemetry, how long the beacon has been switched on for and a URL to the project web page.
Because of the simplicity of the transmitter, it has very poor thermal stability, and is very easily affected by objects touching it/in close proximity to it (affecting the loading of the crystal - it's very cheap!). It won't be of much use whilst the balloon is in the air, but if we lose the payload, this should help us find it once it's on the ground.
Running on 2AA lithium batteries, run time should be close to a week when constantly transmitting, more if the duty cycle is lowered a bit.