Ardupilot + TBS Tracer - How to get telemetry and control data to radio and gcs?

I have a plan to use the a TBS Tracer to connect telemetry and control with GCS and radio.

The radio needs telemetry to present battery state and altitude.
The GCS needs mavlink telemetry to have state control and enable parameter tuning.

Edit: This system shown below does currently work but it is far from robust.

TBS Tracer has very bandwidth limited. What is the best way to setup this system to have best reliability?

The easiest option I can think of is to pipe MavLink on CRSF passthrough. Then OpenTx needs to parse MavLink. This is assuming that the CRSF telemetry rates can be tuned for optimum performance and it has bi-directional communication.

Any better suggestions are welcome.

@andyp1per - continuation of the topic started in issues.

Did you try mavlite? It wasn’t great last time I tried but apparently TBS have made a bunch of improvements.

Also the CRSF 0.9 spec has support for mavlink tunneling, so it would be certainly possible to put this on a single link and it may even be that all you need to do is write the AP integration and then the TX side WiFi/BT might already be able to parse the tunneled packets.

@andyp1per I was not clear in my introduction that this system kind of works but it is slow and inreliable.

Trying to get up to speed on Yaapu Frsky passthrough
Frsy bidirectional thread
Yaapu Ardupilot dev conference 2020

Which seems dependent on FrSky but you say that TBS are working on it. Many things I don’t understand yet.

I may be able to work around the mavlink parameters by buffering them in mavproxy. Need to look into that.

In armed operation the largest waste of bandwidth is having to repeat the gps location messages in crsf with the location messages in mavlink. The transmitter only needs altitude and airspeed at high frequency. Ideally there would be some kind of crsf-mavlink message bridge in the Tracer Tx.

Looks like I am gradually talking my way out of this being an Ardupilot problem.

My airframe is very compact. I don’t see any viable options for the Rx other than TBS Tracer Nano.

Hi, to me it’s not yet clear what you’d like to achieve, anyway:

  • if you want CRSF telemetry + CRSF custom telemetry (yaapu) + mavlink you need to use 2 UARTS and share bandwidth (in the air) between mavlink and CRSF. There only is so much bandwidth and you’ll need to keep the mavlink rates quite low.
  • If you setup only a mavlink connection (1 uart) your TBS gear will “emulate” CRSF telemetry (create fake CRSF telemetry packets from mavlink data) and provide basic CRSF telemetry on your OpenTX radio but yaapu widget will not work. You’ll need to enable RC over mavlink.
  • If you only setup CRSF you can try TBS mavemu (mavlink emulation where your TBS TX will forge basic mavlink packets from CRSF telemetry), yaapu will work but your GCS will have readonly partial mavlink data (i.e. no parameter editor and mission upload)

Since you’re on TBS gear the FrSky docs do not apply to your project :slight_smile:

Alex,
Thanks for the advice. I did not know that Tracer would bridge between CRSF and mavlink. Maybe this all works out of the box.

I don’t go heads down when I fly since I loose track of the aircraft for too long. I rely on audio (height announce and vario). Visual indicators on the transmitter is not a priority.

The GCS connection is intended for a higher level AI informing the pilot or directing directly, possibly flying multiple units together. It has to be bi-directional so your last suggestion is not attractive.

I wonder if there is any trade-off TBS can make between radio update rate and bandwidth? For my aircraft 25Hz udpate would be quite sufficient, maybe as low as 10Hz.

I’ve been attempting to get the pure mavlink connection working and I’ve semi-succeeded. Following TBS’s instructions I’ve connected the receiver with only one UART, enabled RC over mavlink, and setup the parameters in ardupilot. I get the basic CRSF telemetry, the RC link works, and the wifi module is able to transmit the mavlink data to QGC and mission planner (very slowly) but is it possible in this configuration to get the yaapu widget to work?

The yaapu widget requires CRSF proper rather than RC-over-mavlink

So I either need to use only csrf to get yaapu working but then lose QGC functionallity, of leave it as is and yaapu won’t be able to work?

If you have a spare UART you can wire up both mavlink and CRSF, but be aware they share the same link so might affect throughput. You can also use MAVEmu on the TBS side to convert CRSF telemetry back to mavlink

If I use mavemu will I still be able to have full QGC functionallity? Parameter editing, waypoint upload, things like that? I don’t have any extra uarts sadly

No idea, it use to be so-so - it’s been improved a lot in 6.13 I believe

Configuration:

TBS Tracer Nano Tx with Diversity Rx - All , including WiFi updated to latest version

Flywoo Goku GN745 Nano
Tx12 MK2 with EdgeTx

Connection:
Rx Ch 1,2: FC UART 3 Rx,Tx
Rx Ch 3,4: FC UART 1 Tx,Rx
UART1 Baud: 57600, Prot: Mavlink2
UART3 Prot: RCIN (23), Baud: 38400

Yaapu telemetry screen is working fine on Radio
but

  1. unable to get mavlink parameters to download on mission planner
  • it is getting connected though - and
  1. telemetry is v slow. Telemetry is faster on Yaapu though. I wonder how could there be such a difference in telemetry speed on Yaapu and WiFi Link. Looks like inefficient WiFi algorithm?

Update: Sharing for information: I had luck in getting mavlink over wifi on QGC

Trick is to use only Mavlink Tx and Rx. Do not use CRSF along with that as it overloads the link. Use RC over Mavlink in Tx Settings
I am able to change modes etc. from QGC and get telemetry as well