[CBRrunner]

If I'm using the OPlink radio for control on my taranis can I set it up to give telemetry to my controller?

[Brian]

Not currently, but that's something that I would like to implement.

[CBRrunner]

Are you one of the code writers?

I would not think it would be that hard. Than again I am a mechanic.

You would probably have to have a special setup for the OPlink you load from the GCS. The pixhawk does it via a teesey through the taranis RX's telemetry port.

[Brian]

I am the original OPLink developer after Pip, who designed the original hardware and wrote the first version of the firmware.

It shouldn't be hard, but I'm not sure yet what the best path is for getting the telemetry into the taranis.  It would be nice to go through the sbus pin on the module connector, but that would require an inverter.  The other alternative is to go through the uart, which is in the battery compartment.

I would also like to support some sort of higher speed digital protocol to replace PPM, but that also takes further research.

[CBRrunner]

I like the S.bus so I can just stuff it all in my jr transmitter adapter.

What kind of inverter would it be and how hard is it to make and program?

I'm willing to sacrifice a teesey if need be.

[Brian]

This is all the hardware that's needed:

http://www.dx.com/p/signal-inverter-for-naze32-flight-control-sbus-receiver-black-429018#.V4fhKPkrJhE

The firmware is going to take some thought.  It would require getting the info from the FC to the OPLink, which will likely be different between the different modes (control only, or control+data).  It's probably going to need another selection (control+basic telemetry), where it uses a higher datarate and the FC responds to each control packet with telemetry, or maybe it would only send telemetry every n-th control packet, which would be supported over a lower datarate.  Then, of course, there's the packaging the data in the right format to send to the taranis, but that shouldn't be too hard.

[CBRrunner]

Here I thought the hardware would be way more exotic than that 

Will the data transfer degrade flight control performance?

Would it save processing power and reduce packet size to do the telemetry conversion on the transmitter side?

Just bring the raw data into the transmitter from the OPlink radio and then translate it through something else and then send it to the S.bus pin on the Taranis.

This would be Similar to how you can use teensy to translate mavlink data from a pixhawk to the Frsky receiver and then send it to the Taranis. There are some really cool .lau mods out there for that data.

I would gladly test some beta stuff if anything becomes available.

[Brian]

My thoughts are to model it after the OpenLRS telemetry model, where the Tx sends a control packets, and the FC ACKs with a telemetry packet.  I wouldn't want to the telemetry packet to be really any bigger than the control packet, which leaves 9 bytes for telemetry.  That should be enough for battery state, RSSI, etc.

Doing that would require doubling the air datarate over the PPM-only rate, which will affect range some, but I don't expect it to affect it too much.

[CBRrunner]

what is the packet rate? would there be enough fidelity if the telemetry was staggered across the packets?

Could the OPlink be used for telemetry only to the taranis while using a D4r-ii or X type receiver for control and aux systems?

what would be the feasibility of copying the mavlink telemetry workaround by going from the FC to a converter board then to the RX telemetry port then back to the Taranis?

[Brian]

what is the packet rate? would there be enough fidelity if the telemetry was staggered across the packets?

The packet rate is matched to the PPM rate, which is about 50 packets / second.

I hadn't thought about spreading the telemetry over multiple packets, but I think that would only necessary if one wanted to send alot of telemetry.  At 9 bytes of data a packet I believe the overhead is more than the data, so making the return packet smaller wouldn't really help.

Could the OPlink be used for telemetry only to the taranis while using a D4r-ii or X type receiver for control and aux systems?

The easiest way to do that would be to form the telemetry stream that the Tx needs in the FC and just configure the OPLink is a data-only modem.

what would be the feasibility of copying the mavlink telemetry workaround by going from the FC to a converter board then to the RX telemetry port then back to the Taranis?

I've never used "modern" Rxs, so I don't know how that would work.  I assume that should work, but then that's not an OPLink issue, and there may be ways to do that already.

[CBRrunner]

Thank you for the replies.

Is the telemetry data something that's being worked on?

[Sparrow082]

The OPLink and the GPS flight modes are what sold me on Librepilot. The OPLink needs to support full s.bus, and Smart port natively. But instead of trying to make a square peg fit in a round hole, why not build a new OPLink module specifically to cater to FrSky community?

[Brian]

Is the telemetry data something that's being worked on?

I haven't started working on it yet, but I do plan to.  My OpenLRS PR was merged, so now it will be easier to add new stuff.

[Brian]

The OPLink and the GPS flight modes are what sold me on Librepilot. The OPLink needs to support full s.bus, and Smart port natively. But instead of trying to make a square peg fit in a round hole, why not build a new OPLink module specifically to cater to FrSky community?

Are you talking about a Taranis module?  I might actually do that for myself.  It's really not hard to do, and I've made several other iterations of OPLink-like devices, but getting it manufactured is more difficult.

There has also been discussions about replacing the F1 MCU on the existing OPLink with an F3, which supports inverted UART natively.  That would likely be an easier route because the F3 is pretty much a drop-in replacement for the F1, and we might be able to nudge the manufacturers to replace the F1 with an F3.

[CBRrunner]

I'd be down for 2 upgraded oplinks

This maybe a little off topic but will the revo output frsky telemetry to the s.port on a D4r-ii or x series receiver?