Yesterday I put up a fairly involved flight with 3 trackers using 2 new tracking systems, plus a reliable old tracker to make sure I got the payloads back!
One of the new trackers was a “UKHASNet” node, sent up as a last-minute thing following on from a successful flight by others at EMF last weekend. Sadly this tracker wasn’t received at all during the flight. I then discovered a short circuit in the aerial connection to my receiver, but even after that was fixed no data was received. I’ll run some local tests before flying that again.
The main aim of the flight though was to test some new LoRa (Long Range radio) modules. These have been available for about a year now, but due to bandwidth restrictions the earlier modules could not be used on the 434MHz band that ballonists already have aerials for. The new modules however can be used at various bandwidths, with the most useful (for us) being 20.8kHz which fits neatly inside the 25kHz allowed. I opted for the RFM98W device:
LoRa is a modulation scheme that promises much a greater link budget (and therefore range) than did previous single-chip transceivers. This is important since neither the balloon payload aerial (which is swinging and rotating) nor the car aerial (which is bouncing around with trees and/or buildings in the way) is in perfect conditions. Traditionally we have used RTTY and sensitive amateur radio receivers, or modes such as Contestia for greater range, but LoRa appears to offer a workable alternative that of course is much less expensive and does not require a PC to decode.
For the LoRa test flight, I built 2 trackers one with an RFM98W attached to an Arduino Mini Pro, and the other with one attached to a Raspberry Pi. I also made 2 receiving stations with the same modules on Raspberry Pi boards:
The AVR tracker was set to use very slow modulation scheme, theoretically offering the greatest range and the best chance of rivalling RTTY. Meanwhile the Pi tracker was set to use the highest possible speed (within bandwidth limits) over which it sent images (SSDV) as well as telemetry. I did not expect this to work well, as the equivalent RTTY baud rate is 1400 baud which is pushing the ability of receivers to decode.
For 2 LoRa trackers I needed 2 LoRa receivers / gateways, both of which upload received packets to the internet so that the balloons show on the live map, and images appear on the image web site. Additionally I needed a gateway for the UKHASNet node.
All 3 were put on a table outside, so I could attach aerials easily:
Preparing 4 trackers and payloads, plus 4 different receiving/decoding stations, is a lot of work, and my stress levels weren’t helped by the ADSL line going down just as I was ready to fill the balloon! Next job was to tie all 4 payloads together, and that plus the chute and balloon lines took 35 metres of line! Just as well, as we’ll find out later …
The launch itself was easy, once all that line was fed out. Back on the receiving stations, nothing came in from the UKHASNet node at all. After a while I checked the connections, and fixed a short where the aerial wire connects to the radio module, but still got nothing. I’ll investigate further and fly another test soon.
LoRa1 and 2 however were doing very well. Initially LoRa1 was a fair bit stronger than 2, but the aerials were different. When LoRa2 started to drop out, I replaced both with Yagi aerials and the signal strength went up by several dB of course. Now LoRa2 was stronger, and remained so throughout the flight. The Yagi on LoRa2 was higher gain than on LoRa1, but not high enough to explain the difference, so that’s another thing to look at.
With the Yagi aerials in place, both trackers were received with near 100% success, with LoRa2 outperforming LoRa1 despite the higher data rate. More testing needed, but it seems that the slower data rate isn’t as much of an advantage as it should have been. Nevertheless, packets were decoded by Philip Heron in Northern Ireland so it was working pretty well! He reported results not quite as good as RTTY over that distance, and perhaps with some tweaks this can be improved. Looking at the data after the flight, my stations received down to 1800m altitude (LoRa1) and 1400m (LoRa2), so comparable with what we managed in the car from the RTTY payload. Overall then, a very good result. I don’t know how well LoRa will work to a mobile tracker in a chase car, or how well it will work after landing, but the suggestion is that both will be good enough for HAB.
I watched the incoming data and images till the flight burst. The only real issue was that LoRa2 stopped sending position data above 12km, which means that the “flight mode” code failed, probably due to errors in the serial port settings (usually my Pi payloads use I2C not serial for the GPS, and I probably got something wrong in the conversion). After burst, we waited for the landing prediction to settle, then set off in the chase car. This time we didn’t take any kit to receive the LoRa trackers (that’s a job for next time) but did of course take the usual kit for receiving the RTTY tracker.
After losing the signal at about 1800m altitude, we proceeded to the expected landing area, found some high ground then parked up to tune in to the signal which was quite strong. We decoded a few sentences and as we did I noticed that the payload position appeared to be changing! Normally the GPS position bounces around by a few metres, but this one was consistently moving north! Checking on the OS map on my tablet, we could see the position was on the golf course which we’d passed a few minutes before, so we headed back there, got an update on the position, then went inside to find someone in charge. That didn’t take long, and we were allowed on the course with instructions to keep out of the way of the competition that was still ongoing at the end of the course!
I had an app running on my phone showing the distance and direction to the last known position of the payload. What I couldn’t tell (but suspected) was that it had moved! Indeed, as we got closer, some golfers called us over as they’d retrieved the payloads and had them strung up around a trolley!
He explained that they’d spotted the payloads next to the green at the 15’th. Looking at the images afterwards I could tell that some of the payloads were in a tree, so they’d dragged those down. This screenshot shows where the lower payload was when we first received it after landing, and its path.
So, a very successful flight, with payloads recovered and LoRa performing rather better than I expected (for a first flight). Some issues to look at and some more testing to be done, but it all looks promising.