[Marico]

For those who are interested with long range telemetry: I tested SIYI FM30 transmitter module & FR Receiver. It works on 2.4GHz  band and it's advertised as 30km range radio with high noise/interference tolerance. It has transparent UART channel (57600 bps) which can be used to send telemetry data. FM30 transmitter module has a Bluetooth module so it's nice feature to connect wirelessly with GCS or Android phone. I tested telemetry and it works nice.

[TheOtherCliff]

Telemetry (requires the receiver to have good transmit power too) and Bluetooth make this attractive.

In the interest of facts and shooting down false advertising, I feel I need mention a few things I discovered.

The 30km/40km ads and the videos of the long range tests are misleading.  All the videos I watched use directional antennas.  You can pretty much go any distance you want with a small amount of power by using a lot of directional gain. 

The international version of this is 23dBm (200mW, not very powerful), but will be further limited by law to "less than 100mW" in the USA and other countries.  That is the power of a normal RC transmitter on 2.4GHz.  Also, I recall laws that further limit the power you can transmit with from airborne (receiver).

If you can get the most powerful 200mW version, this seems to be a radio that goes about 1.4 times as far as a normal RC radio and has full range telemetry and bluetooth.  (It takes 4 times the power to go twice as far.)

Further reading:
https://www.rcgroups.com/forums/showthread.php?3764179-A-39-9-Radio-Module-SIYI-FM30-2-4G-30KM-OpenTX-Transmitter-with-Datalink-Bluetooth

[Marico]

Telemetry (requires the receiver to have good transmit power too) and Bluetooth make this attractive.

In the interest of facts and shooting down false advertising, I feel I need mention a few things I discovered.


The 30km/40km ads and the videos of the long range tests are misleading.  All the videos I watched use directional antennas.  You can pretty much go any distance you want with a small amount of power by using a lot of directional gain. 

You are right, but besides power and used antenna/gain the other things like type of modulation, noise immunity, signal selectivity plays important role, too. And it looks like that these modules handle it well for reasonable price (similar long range  modules like FRM302 are more expensive). In my case I had problems with my old 2.4GHz Corona modules, flying was not smooth, above 250m in the distance often I had sudden changes in direction and I suspect my rf link was prone to interference from some sources (copter itself or from area where I'm used to fly). I did couple test flights with FM30 and stock antennas and flights was smooth. Rssi in the distance of 800m was still 89% (it was the farthest distance I tested till now).
I'm planning  make further  tests it with my glider, copter as aircraft is not efficient for distance flights...
Additionaly FM30 was attractive to me because of integraded Bluetooth. BTW is it possible to use one telemetry channel for 2 devices? On my Revo I have free only one UART and it's configured for telemetry. My OSD is connected to it, but I wonder  if telemetry OSD (not mavlink) could work only with RX or it needs TX (talks to Revo), too? If not maybe I could share the telemetry channel with OSD and GCS...

[TheOtherCliff]

Receiver sensitivity / selectivity / noise floor are just as important as transmitter power, but people understand  transmitter power and their eyes start to gloss over if you start talking about the receiver end.

I suspect that given the same antennas in all cases, a good quality RC radio would give approximately equal range to the 100mW FM30.  Futaba for instance has some really good signal processing stuff that can pick up a signal out of the noise floor (my understanding).

A note: RSSI in many 2.4GHz systems is actually the packet loss ratio, not the log receiver signal strength.  Once it starts to drop, you are on the fringe.  It can drop to zero quickly.

My recollection is that if you use Revo telemetry for OSD then if telemetry is out of range, the telemetry stream stops (does not get polling from GCS) and the OSD telemetry freezes.

We used to be able to declare the aircraft to be the coordinator (polling master) and the gcs as the non-cooordinator (slave) to work around this.  I mentioned this, but the change had already been made...

The telemetry code is more complex than just a virtual UART.  It packages up the telemetry into the 256 byte blocks that the RFM22 expects.  It also benefits from knowing how much data to receive.  It doesn't have to wait for a receive timeout/etc to transmit.

[Marico]

My recollection is that if you use Revo telemetry for OSD then if telemetry is out of range, the telemetry stream stops (does not get polling from GCS) and the OSD telemetry freezes.

That's interesting, could You be more specific about this? As I understand it could be issue when the OSD is connected to telemetry data received on the ground but how could this be a problem when telemetry port is connected to OSD on the copter (the classic way: camera-> osd (data from revos's telemetry port)-> vtx)?
I even tested OSD without TX (OSD TX) connected to Revo at all and it works,  so I will be able to use the same Revo's TX/RX port to feed telemetry to the OSD and the GCS (TX feed OSD and GCS, RX receive from GCS).
On other hand connecting  OSD to telemetry received on the ground has the adventage in (post) video editing. Connecting the second OSD module on the ground to the downlink telemetry data but without input video we get "clean" (without noise) video with "rendered" flight data which could be later overlayed in post editing with HD stream recorded on the copter (I'm currently working on such setup).
 

[TheOtherCliff]

It's been a long time...

As I recall someone tried to solder a Y into the normal telemetry stream (to give data to MinOpOsd).  Now that I think about it, it must have been CC3D + OpLink rather than Revo with it's built-in OpLink.

It worked until telemetry was out of range.  The reason that it failed then is that the telemetry coordinator (GCS end) polls the non-coordinator (aircraft end).  The non-coordinator is only allowed to send ... in response to a poll request.  The buffer backs up.  It stops sending packets.

Long ago, this could be worked around by declaring the airborne end to be the coordinator.  That may still be possible, but in some cases it makes assumptions that coordinator is ground (e.g. and thus PPM is input from the RC transmitter, not output) and that non-coordinator is vehicle (e.g. and thus PPM is output to give to the FC).  So if you are using OpLink for PPM control, the ground must be the coordinator.

[Marico]

Long ago, this could be worked around by declaring the airborne end to be the coordinator.  That may still be possible, but in some cases it makes assumptions that coordinator is ground (e.g. and thus PPM is input from the RC transmitter, not output) and that non-coordinator is vehicle (e.g. and thus PPM is output to give to the FC).  So if you are using OpLink for PPM control, the ground must be the coordinator.

But I disabled OpLink at all, so which one  is the coordinator/non-coordinator then? I just feed telemetry data from Revo (configured on Flexi port) via receiver downlink.

[TheOtherCliff]

The "coordinator" concept is part of the OpLink code, call it the transport layer.  Telemetry is a higher layer that creates data for the transport layer and doesn't know (or typically at least shouldn't know) anything about OpLink.

It sounds like you could try a Y cable to get the telemetry data, and if it is the right uart data format (databits, stopbits, baud, etc.), content (OP UAVOs or MSP, including versions and minor variations) and container (nothing that makes it hard to find the packets, like a wrapper that causes a stupid OSD algorithm to do a false start and then miss the real packet start) for your OSD, it will work.  I am guessing that there is no handshaking required by the OSD.  If there is, it would be a problem.  Maybe run it at a lower baud rate so it doesn't need handshaking.  I am guessing there is no handshaking with the receiver or you would have the same issue as described before... if RC receiver is out of range, the OSD stops updating.  That may or may not be an issue for you.

[Marico]

I am guessing that there is no handshaking required by the OSD.  If there is, it would be a problem.  Maybe run it at a lower baud rate so it doesn't need handshaking.  I am guessing there is no handshaking with the receiver or you would have the same issue as described before... if RC receiver is out of range, the OSD stops updating.  That may or may not be an issue for you.

OSD based on telemetry has two working modes: passive and active. I checked in the source code and when passive mode is active there is no (packets) reply from OSD to Revo, so it should works (as far as it's in range).