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
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