[mr_w]

With Revo and Sparky2 having oplink integrated, it is quite tempting to use it also for remote control. Now, what would be the benefits of using 100mW oplink for control, versus for example FrSky X4RSB?

Range?
Link quality?
obstacle penetration?

I know in general the differences between 433mhz and 2.4ghz, but specifically oplink with its low power output, compared to decent 2.4ghz link (assuming X9D+ with X4RSB would be decent setup?).

[lucas]

The main difference will be latency.  OPlink uses CPPM protocol and the X4R SB uses the faster Futaba S.Bus serial protocol.

That being said there are a couple improvements proposed for future releases:

https://librepilot.atlassian.net/browse/LP-265?jql=

https://librepilot.atlassian.net/browse/LP-264?jql=

I already casted one vote for LP-265

[mr_w]

It is my understanding that the latency would be problem only for fast fpv racers. Or is the Oplink latency all that bad? How does the cppm rate oplink uses related to com speed settings in GCS?

[rmcferon]

I'm a noob and I use OP Link for Control and Telemetry. I first used my standard receiver and then changed to the OP Link. I can't see or feel any difference in control and I don't have to find a spot to mount my receiver.

Like I said, I'm new to this so there isn't any FPV racing or heavy aerobatics in the mix. Just some flips and rolls and fast flying close to the ground. No issues with LOS range.

[lucas]

It is my understanding that the latency would be problem only for fast fpv racers. Or is the Oplink latency all that bad? How does the cppm rate oplink uses related to com speed settings in GCS?

Yes you are right, the difference between CPPM and S.BUS will only be an issue for fast FPV racers. 

The CPPM used by the OPlink is the one the Radio outputs on the Pin where the OPlink gets the signal from.  In the case of the Taranis the CPPM frame length is 18 or 27ms. Plus a couple ms that the Radio uses to output that signal on Pin # 2 of the rear module bay.

I'm a noob and I use OP Link for Control and Telemetry. I first used my standard receiver and then changed to the OP Link. I can't see or feel any difference in control and I don't have to find a spot to mount my receiver.

Like I said, I'm new to this so there isn't any FPV racing or heavy aerobatics in the mix. Just some flips and rolls and fast flying close to the ground. No issues with LOS range.

You sir officially graduated past noob stage when you setup a control link with your OPlink

What antennas are you using?

[nitromethane]

OPLink is nice because it does telemetry and control using one radio, penetration should be better than 2,4GHz and range should also be awsome with good antennas at low comm speeds.

I get pretty good performance with some DIY antennas, better than with the usually included cheap ass antennas.

[mr_w]

This with latency got me doing some digging around.

Oplink sends ppm as 8 channels of 9 bit data, making this 9 bytes in total 72 bits. Radio data header and crc at the end are another 120 bits. This makes for at least 190 bits of data for ppm, without any telemetry included. At 9600 com speed, but because of the half-duplex link, the actual radio data rate is set to double of that. Nice. But not so. Apparently, oplink frequency hopping function says this: "Divide time into 8ms blocks.  Coordinator sends in first 2 ms, and remote send in 5th and 6th ms." So out of 8ms, the sending side gets to use 2ms for sending. That is 25% of the total time available. Effective rate of 9600 link (that is 19200 data rate) ? 4800 bps.

Am I wrong? At 4800 bps, it takes 39 milliseconds to send one ppm packet. Comparing this to ~20ms of CPPM, it is twice as slow.

All this is not including any telemetry at all. My best guess is that telemetry on the same link is going to bring the effective ppm data rate really low.

So it seems, when using PPMONLY mode, I would need to set com speed to at least 19200 to have CPPM speed. More for telemetry.

Am I correct here?

[lucas]

Baud rate is only for telemetry. 

When you select PPM Only the Com Speed value is greyed out and you cannot change it. 

[Brian]

This with latency got me doing some digging around.

Oplink sends ppm as 8 channels of 9 bit data, making this 9 bytes in total 72 bits. Radio data header and crc at the end are another 120 bits. This makes for at least 190 bits of data for ppm, without any telemetry included. At 9600 com speed, but because of the half-duplex link, the actual radio data rate is set to double of that. Nice. But not so. Apparently, oplink frequency hopping function says this: "Divide time into 8ms blocks.  Coordinator sends in first 2 ms, and remote send in 5th and 6th ms." So out of 8ms, the sending side gets to use 2ms for sending. That is 25% of the total time available. Effective rate of 9600 link (that is 19200 data rate) ? 4800 bps.

Am I wrong? At 4800 bps, it takes 39 milliseconds to send one ppm packet. Comparing this to ~20ms of CPPM, it is twice as slow.

All this is not including any telemetry at all. My best guess is that telemetry on the same link is going to bring the effective ppm data rate really low.

So it seems, when using PPMONLY mode, I would need to set com speed to at least 19200 to have CPPM speed. More for telemetry.

Am I correct here?

It's been a while since I wrote the code, and I think some of it has changed since I wrote it, but I think you're getting some things mixed up.

The 9600 bps sounds right, and if it's PPM only, it's unidirectional, so the uplink uses the entire bandwidth.  The baud rate is set to closely match CPPM timing, so PPM packets should be sent over the link at about the same rate as they are read/produced at the ends, and the baud rate is no user modifiable in PPM only mode.

I believe the timing that you're referring to (the 8ms blocks) is when running in bi-directional mode.  In order to not have both ends transmitting at the same time, time is divided up so that the coordinator has 2ms to start sending a packet.  If the receiver doesn't start receiving a packet in that time, the receiver has 2ms in which to start sending a packet, and then there's 4ms buffer before the sequence starts over again.  That helps to eliminate collisions where both radios are transmitting at the same time.

In PPM+telemetry mode, the PPM data is sent with each packet from the coordinator to the receiver as "sideband" data.  The data rate needs to be higher, of course, to accommodate the telemetry, but I believe I adjusted the packet size to maintain about the same packet rate so that PPM packets would still arrive at about the same rate as the CPPM frames are received/sent.  That's a part of the code that I think might have changed since I wrote it, but it's not critical.

Edit: I should also note that the baud rate that is set in the GUI is the com baud rate.  The over-the-air baud rate is set automatically based on that, and it would be higher than the com baud rate to account for header information, etc and bidirectional traffic, but I don't think it's twice the com baud rate, with the assumption that the com data is likely asymmetric (telemetry downstream, but just PPM + ACKs upstream).

[mr_w]

Brian, thank you for making things mostly clear now.

The only thing I do not understand at the moment (and that only because I didn't read all of the code yet) is this - for example at 9600 com speed, oplink hw init sets data rate to 19200. Rfm22b preable, sync, length, checksum are some 120 bits long. Give or take few. At 19200 rate, that takes 6.2ms to send out. Without any payload. How is this split to 2ms frames every 8ms?

Please tell me that I am horribly wrong somewhere?

I just want know for sure, what com speed should be set, to have at least matching CPPM rate and have working telemetry, as this is all what it is about here - the possible benefits of using oplink for telemetry and control at the same time.

[rmcferon]

I am using 57600 rate for PPM+Telemetry with a half wave dipole antenna on my quadcopter and a short monopole (Rubber Ducky) on the Tx. As I said before, I haven't had any issues with LOS range yet.

[mr_w]

57600 rate sounds good for ppm+telemetry, but makes me wonder how the range compares to ppm only @9600. When you say LOS, thats just couple 100s of meters, right?

[rmcferon]

As the baud rate increases the range will decrease. The open area at the park I use is 250 meters. I use all of that in one direction.

 I just updated the firmware on my OSD to the Revo only next branch to see if the RSSI will work.

It's been raining an windy so I haven't been able to try it yet.

[Brian]

The 8ms cycle is only when neither side is transmitting a packet.  When one side starts transmitting a packet it takes however long it takes.  When the packet transmission is complete, it starts the 8ms cycles again to coordinate sending another packet.

As for PPM+telemetry, I think you need to use at least 57600, unless you tweak your UAVTalk parameters to slow down sending updates.  The range will be shortened, but that's the amount of bandwidth that standard telemetry requires.

I would really like to have a lower datarate telemetry that only sends "important" information at a slower rate (battery status, GPS location / heading, etc), but that's not currently supported (AFIK).

[mr_w]

I did some testing, and with 9600 com speed, with telemetry enabled, ppm is sent 12 times per second. 57600 makes it neat at 50 per sec.

At first I was thinking it does switch rx/tx all the time every 8ms, and it seemed that PPM transfer would not be as much affected by telemetry because they travel in opposite directions. However, your explanation makes it really clear on why telemetry does affect it that much.

So the conclusion would be that oplink for telemetry and control is for short range only.