This was my second test flight of my 868MHz LoRa fast SSDV (Slow Scan Digital Video) software, to celebrate my 58th flight and 56th birthday.
I made some changes to fix some issues with the previous test flight:
- Set RTTY baud rate to 300 to prevent RTTY Tx during LoRa Rx period
- New MTX2 programming code
- Replace the UBX GPS code with NMEA code
The RTTY overrun was due to accidentally leaving the tracker at to 50 baud after a brief test. The 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. Although the frequencies are very different, this still slightly deafened the LoRa receiver and meant that only 12 messages were uploaded during that flight.
When the Pi starts up, 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). This was resolved and extensively tested.
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. I 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.
I also made some changes to the SSDV code, storing telemetry in the JPEG file comment field, by using the EXIV2 program. This 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. I added such a script using ImageMagick for the rendering.
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.
The 868MHz antenna was below the payload with a 434MHz stubby antenna above (not an ideal position, but usable, and avoids compromising the 868MHz antenna).
Total weight including 18″ Spherachute and cord is less than 250g. Ascent rate was targetted at 4.5m/s with an expected burst altitude of 31-32km using a 350g Hwoyee balloon filled with hydrogen.
The launch was easy enough, with very little wind (good, as I was alone). There 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. After a while though it was high enough to see some better weather and so we started to see some better images:
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.
As the flight approached peak altitude, the pictures improved markedly, with this probably being the best one. For comparison, I’ve inserted a live image from my very first Pi flight, at the same scale in pixels. Roughly, the new image has 10 times the number of pixels, and took about 1/10th of the time to transmit.
For this flight there were 2 other gateways set up by other HAB enthusiasts, as well as my too. Even with this limited coverage we still lost very, very few packets. I had my Python script running to check for missing packets, and creating uplink messages to request repeats of those packets. Throughout 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.
With 3-4 gateways running we again saw an issue with SSDV uploads timing out. I’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. Phil 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.
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):
Since the flight was mainly about testing the radio side, I stayed at home checking the radio communications, aiming and swapping aerials, until the flight had descended beyond my range. I then prepared the chase car and checked the final descent positions and landing predictions. The landing area was just south of Avebury, near Cherhill White Horse, and about 1 mile from the nearest road. From 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. I made sure to pack walking boots, backpack and mobile tracking gear as this wasn’t going to be a quick and easy recovery!
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. Nothing. As 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.
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. That sounded like a better (easier!) bet, especially as I thought the payload would be in that valley. Sure enough, as I got closer, the radio burst into life with that familiar RTTY sound. I sat down to get the laptop set up, and the signal almost disappeared – it really made a huge difference how high the aerial was. So, with laptop and radio on the ground, I held the aerial up to get a decoded position.
Unsurprisingly then, the payload position turned out to be in the valley below:
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:
On the way I caught my first glimpse of the payload below (parachute on left; payload on right):
So in the end, not a difficult recovery if we ignore the steep climbs!
For more photos, click this image: