The RTTY overrun was due to accidentally leaving the tracker at to 50 baud after a brief test. \u00a0The 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. \u00a0Although the frequencies are very different, this still slightly deafened the LoRa receiver and meant that only 12 messages were uploaded during that flight.<\/p>\n
When the Pi starts\u00a0up, 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). \u00a0This was resolved and extensively tested.<\/p>\n
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. \u00a0I 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.<\/p>\n
Additions<\/h2>\n
I also made some changes to the SSDV code, storing telemetry in the JPEG file comment field, by using the EXIV2 program. \u00a0This 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. \u00a0I added such a script using ImageMagick for the rendering.<\/p>\n
Payload<\/h2>\n
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.<\/p>\n
![\"\"](\"https:\/\/pbs.twimg.com\/media\/CcELuKXW8AE5llr.jpg\")
<\/p>\n
The 868MHz antenna was below the payload with a 434MHz stubby antenna above (not an ideal position, but usable, and avoids compromising the 868MHz\u00a0antenna).<\/p>\n
![\"\"](\"https:\/\/pbs.twimg.com\/media\/CcELdfJW8AAAMM8.jpg\")
<\/p>\n
Total weight including 18″ Spherachute and cord is less than 250g. \u00a0Ascent rate was targetted at 4.5m\/s with an expected burst altitude of 31-32km using a 350g Hwoyee balloon filled with hydrogen.<\/p>\n
Flight<\/h2>\n
The launch was easy enough, with very little wind (good, as I was alone). \u00a0There 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. \u00a0After a while though it was high enough to see some better weather and so we started to see some better images:<\/p>\n
![\"\"](\"https:\/\/pbs.twimg.com\/media\/CeOxL8hW8AA8hiQ.jpg:large\")
<\/p>\n
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.<\/p>\n
As the flight approached peak altitude, the pictures improved markedly, with this probably being the best one. \u00a0For comparison, I’ve inserted a live image from my very first Pi flight, at the\u00a0same scale in pixels. \u00a0Roughly, the new image has 10 times the number of pixels, and took about 1\/10th of the time to transmit.<\/p>\n
![\"\"](\"https:\/\/pbs.twimg.com\/media\/CeT0zyhXEAAjEOo.jpg:large\")
<\/p>\n
For this flight there were 2 other gateways set up by other HAB enthusiasts, as well as my too. \u00a0Even with this limited coverage we still lost very, very few packets. \u00a0I had my Python script running to check for missing packets, and creating uplink messages to request repeats of those packets. \u00a0Throughout 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.<\/p>\n
With 3-4 gateways running we again saw an issue with SSDV uploads timing out. \u00a0I’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. \u00a0Phil 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.<\/p>\n
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):<\/p>\n
![\"\"](\"https:\/\/pbs.twimg.com\/media\/CePF3cyWwAA2DxC.jpg:large\")
<\/p>\n
Recovery<\/h2>\n
Since the flight was mainly about testing the radio side, I\u00a0stayed at home checking the radio communications, aiming and swapping aerials, until the flight had descended\u00a0beyond my range. \u00a0I then prepared the chase car and checked the final descent positions and landing predictions. \u00a0The landing area was just south of Avebury, near Cherhill White Horse, and about 1 mile from the nearest road. \u00a0From 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. \u00a0I made sure to pack walking boots, backpack and mobile tracking gear as this wasn’t going to be a quick and easy recovery!<\/p>\n
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. \u00a0Nothing. \u00a0As 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.<\/p>\n
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. \u00a0That sounded like a better (easier!) bet, especially as I thought the payload would be in that valley. \u00a0Sure enough, as I got closer, the radio burst into life with that familiar RTTY sound. \u00a0I sat down to get the laptop set up, and the signal almost disappeared\u00a0– it really made a huge difference how high the aerial was. \u00a0So, with laptop and radio on the ground, I held the aerial up to get a decoded position.<\/p>\n
![\"\"](\"https:\/\/pbs.twimg.com\/media\/CeP0d3tWQAAb8H9.jpg\")
<\/p>\n
Unsurprisingly then, the payload position turned out to be in the valley below:<\/p>\n
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:<\/p>\n On the way I caught my first glimpse of the payload below (parachute on left; payload on right):<\/p>\n![\"listening\"](\"http:\/\/www.daveakerman.com\/wp-content\/uploads\/2016\/03\/listening.jpg\")
<\/a><\/p>\n<\/a><\/p>\n