On February 16, the EDGE Research Lab team launched EDGE4 (flight summary), a relatively light flight designed to inform infrastructure decisions for our research project. The flight lasted almost 5 hours, reached a max altitude of 106,504 feet, and traveled 165 miles downrange. Of particular interest to this community is the head-to-head test that we did comparing the reliability and performance of the 9xTend (our standby radio for years - starting well before the formation of the EDGE team) against the recently released RFD900 (originally announced here on DIYDrones: RFD900 - New long range radio modem). A full writeup of the testing scenario, configuration, and the results can be found on our report page, but here's the short version: from a link speed and reliability perspective, the RFD900s are amazing. Here's a side-by-side comparison of the GPS tracking information that we received (xTend on the left, RFD900 on the right):
This was captured from two different chase vehicles at the same location, about 41.5 miles line-of-sight from the balloon at the time. The advantages of the built-in diversity and filtering on the RFD900 are clearly evident. Also, in case you're wondering, ground-based testing of the two payloads side-by-side indicated no substantial difference in the noise floor reported by either of the receiving stations with the other radio on, so they're not interfering with each other.
Big kudos to Seppo and his team at RFDesign; they've put together a phenomenal radio. We went into this test expecting to come out with a clear choice to stick with the xTends for our operations, but this result has us seriously reconsidering. On top of all of the performance goodness, these radios operate on the same SiK open-source firmware as the 3DR 900MHz radios!
Comments
All good info, thanks! The GPS units send 4 NMEA sentences once every second (GGA, GSV, GLL, and RMC), so they're pushing an average rate of about 1.6kbits/sec. Not a lot, I know, but the point of this test was (as close as possible to) identical data that was as easy to transmit and receive for reliability comparison.
The Rx sensitivity of the GPS unit matters mostly for when the payload is back on the ground. When it's on its side (or worse, hanging from 8.5' cornstalks with the GPS antenna pointed at the ground), we've found that a really sensative GPS module - even with a patch antenna - seems to outperform lower sensitivity modules with helical antennas.
And, FWIW, "wierd" is a charitable term to use when describing FCC regs... :-)
looking at the options you chose, you really should have had ECC on. You should probably also try the OPRESEND option, as that will cope with long stretches of interference.
The ECC will gain you a few dB. That could increase your range by 50% or more. It costs half your bandwidth, but if you aren't bandwidth constrained it will be very worthwhile.
How much data does that send per second?
Also, I'm curious as to why RX sensitivity matters for a GPS in a balloon. Wouldn't you get great reception up there? :-)
If you want to stick within FCC regs, one thing you could do is add a SiK setting "NOSYNC=0/1" which would tell the radio not to do its normal hopping synchronisation. You'd only set this on one end, and at the other end you'd set the duty cycle to zero. Then you'd have a one way link, and no synchronisation issues.
Of course, you may want to send commands up to your payload at some stage, in which case you'll want the 2-way link again :-)
btw, I assume you know about the weird FCC rules in the US about the first few dB of antenna gain not counting to the EIRP limit? I think it might be the first 6dBi. That allows you to have a higher gain antenna on the ground. If you set it up as a one way link then you can of course have a massive ground antenna, as you aren't transmitting.
If you do use a one-way link then one thing to watch out for in the balloon is that the antenna diversity does the right thing. If it never receives a packet then it won't know which antenna to transmit on (its based on the signal strengths during reception of a preamble). If you fly with only 1 antenna in the balloon and do a 1-way link then you would want an option to disable the antenna diversity and force one of the antennas.
Cheers, Tridge
@Andrew: for this first flight, we kept it simple - just a GPS transponder, as you put it - so no noise data collected during the flight. However, based on this performance, we will be flying and characterizing the RFD900 further.
Here's a picture of how we set up the two radios; the ground unit is on the left, air unit is on the right:
We set up the symbol rates differently for a couple of reasons: first, the 9xTend only supports 9.6k and 115.2k symbol rates. Second, there was concern about the TDM sync time required for symbol rates of less than 16k; there's no doubt that the SNR would be better at a lower symbol rates, but clearly there wasn't a problem at 16k, and our research payloads won't have a difficult time taking advantage of the extra headroom.
As far as the GPS goes, we flew identical Navisys GM-301 (SiRFstarIII) with the altitude restriction disabled. They're pretty basic as GPS units go, but they have demonstrated reliability and really great Rx sensitivity (-159 dBm, if memory serves), so for this test, they were an obvious choice. They output raw NMEA data via a 4.8k TTL serial stream.
The option of limiting the number of channels to overcome the TDM sync issue is very novel, and ham licenses aren't a problem; however, we're probably not going to be using ham bands during our research phase to avoid any chance of complaints about "commercial use" even though we're a non-profit...
We'd love to do a g+ hangout with you at some point! Look for a PM with additional info. Fantastic work on the SiK FW.
Jack V Crossfire, that's over the top, even for you. Of course it can't make a pizza, but it can how ever plop one on your house from orbit. Frozen or carbon, it's your choice, dagnabit. Why don't you get with the times?
Almost all the features came from competing in the outback challenge, while Maxstream/Digi has had no such contest motivating any improvement to it's product in over 6 years. But to be sure, a radio should do more than just implement a UART, multiple error correction schemes, temperature monitoring, time division multiplexing, heartbeat responses, diversity, & an atomic clock. It should also make pizza, damnit.
Thinking about it a bit more, I think a custom SiK firmware for GPS transponder usage like this is warranted. I think it would be best to decouple the serial stream from the GPS from the serial stream going over the air to the other radio.
You can get this to some extent using the OPPRESEND option to get the balloon radio to opportunistically re-send the last GPS packet, which will allow you to cope with lost packets better, but I think we can do better than that.
What we'd do is have code in SiK that reads the GPS and populates an internal structure with the various GPS packets. It would then send these packets over the air at whatever data rate it can manage (taking into account the configured duty cycle). This means if there is spare air time available it would send the last GPS packet again, and if there is more data coming from the GPS than it can get through then it would avoid corrupting the stream by ensuring that only whole GPS packets are sent.
It would also allow you to customise the packet format used over the radio link. You could remove pieces of the GPS messages you don't need, and add additional information like the radio signal and noise levels, and the radio temperature.
I suspect you could get ranges well over 200km if this was done right.
Cheers, Tridge
Nice test, thanks for sharing!
Did you happen to record the local and remote signal and noise figures for the radios during the flight? If you send a MAVLink heartbeat message to a RFD900 radio then it will respond with a 'RADIO' packet that tells you the signal strength at both ends, the noise level at both ends and the number of error corrected packets.
I'm also curious why you set the AIR data rates differently for the two radios. The RFD900 should handle 8kbits fine.
Finally I'm curious what other RFD900 settings you had. For example, did you enable ECC, and what serial rate did you setup? I'm guessing your GPS is probably configured to send 1 position message per second, which for a uBlox would be about 100 bytes/second (very roughly, you should measure this). So that means you have ample bandwidth, and you could gain some advantage in range by enabling ECC to fix up to 25% corrupted bits.
You should also experiment with two other parameters. The DUTY_CYCLE parameter would allow you to set the receiving radio as receive only (just set DUTY_CYCLE to 0). That would allow you to have multiple ground stations. If you do this you would also need to set NUM_CHANNELS to 1, to avoid the radio in the balloon trying to resync its transmit channel with a radio that isn't transmitting. That assumes you have an appropriate HAM license to operate a 30dBm transmitter with no frequency hopping.
I'm also curious which GPS you used, and what mode it was in (eg. a uBlox in NMEA mode). It might be worthwhile to teach the SiK firmware about GPS protocol boundaries, just like it can be told to honor MAVLink protocol boundaries. The advantage is that if it always puts whole GPS packets into radio packets then you will greatly reduce your packet loss rate, as a lost packet will only lose one GPS packet, not two. Understanding the GPS message boundaries would also make it possible to insert additional data from the radio into the data stream, including the signal and noise levels, and the reading from the radios internal temperature sensor.
Finally, I did very little testing of the SiK firmware at very low baud rates. A GPS doesn't produce much data, so you'd probably get the best range at a very low baud rate. It may be that some tweaking of the radio register table is needed for reliable communication at low baud rates. You probably also should disable the REGULATORY_MAX_WINDOW, which will prevent low baud rates from sending decent sized packets (this max window is 0.4 seconds, and is the maximum allowed dwell time on a channel under FCC regulations).
Let me know if you want to do a G+ hangout sometime to discuss how the SiK firmware could be adapted to better suit high altitude ballooning.
Cheers, Tridge
Very impressive! From that data, the clear advantage goes to the RFD900. The price is very reasonable too. I'd be curious to know the maximum reliable receiving distance is (published is >40km, you tested to 67km at nearly 100% data received... very cool!).