Passthrough telemetry over CRSF (crossfire)

Development Team
1082
  1. now I get what you say: YES when we know in advance that a value is positive the sign bit is overwritten to save bits for othe data.

This data format predates my involvement in the project so, just like you, I had to “adapt” to it

This is the protocol in it’s current form, Frsky Passthrough Protocol - Google Sheets

1083

concerning your FrSky question: What I actually think could be a (very!?) worthwhile thing to do is a MAVLink message which can carry an array of passthrough datagrams. IMHO this would have two advantages:

  • some of the data required for converting to passthrough are not so easily obtained from the MAVLink messages, like e.g. battery parameter values and other. So one could e.g. just send the missing data, or in fact just send them all given it’s not very spaceous.
    (which - what a coincidence - would be then essentially your idea, just wrapped into MAVLink)(and motivated form a different angle LOL)
  • it could be a “better” kind of high latency message. I must admit I am not excited about the new HIGH_LATENCY2 at all, as it misses quite some data one would often want to have, so it is useful onyl for really specific cases. However, given that the passthrough telemetry is time proven, such a MAVLink message would indeed deliver a more widely useful high latency message, and more over, it would be very flexible in its content!

I think it could really address a number of issues.

EDIT: one in fact could just use the existing TUNNEL message !!! I guess I should do a sample implementation…

1084
  1. ok
  2. ok
  3. ok (yeah, I know that google sheet very very well by now LOL)

MANY THX!!!

1085

haha @olliw42 I knew you’d give it a try, would solve all your issues in an elegant and transparent way :slight_smile:
MAVLINK TUNNEL is the way to go, really good idea

1086

it works :). (the mLRS and telem app thing, not the tunnel thing)
Many thx for your help, much appreciated.

https://youtu.be/m1uDWcwcknM

2 Likes
1087

What a great job, congrats!

1088

Got almost everything working. Taranis X9D Plus, EdgeTX, ELRS and Yaapu Telemetry. The only problem I have is with altitude. The correct altitude relative to home is displayed on the telemetry page. ASL altitude is also correct. However, if I try to display the relative altitude on another telemetry page using the variable Alt, I always get the same value as GAlt. I can’t figure out why I can’t properly display Alt. Thanks.

1089

@yaapu
Hey Alex, here is a first attempt at implementing the passthrough via mavlink idea: SPort Passthrough telemetry via MAVLink (WIP, do not merge) by olliw42 · Pull Request #21781 · ArduPilot/ardupilot · GitHub. Is for copter, hope you may have a look at it nevertheless :slight_smile:
Olli

1 Like
1090

Hi @olliw42 I saw your PR and quickly read through it, you already know I like the idea :slight_smile:

1 Like
1091

I can make the script running on my Radiomaster TX16 with Nano RX and CUBE ORANGE wit Plane 4.3.0 beta1

I am working on a new build with a MATEK H743 SLIM V3, I loaded latest Beta and connect to SERIAL1 (Mapped to USART and it is working as I can read MavLink) but I cannot get Telemetry reading

I mad a custom build with these features, but still no data
{“selected_features”: [“EKF3”, “UBLOX”, “BMP085”, “BMP280”, “BMP388”, “DPS280”, “FBM320”, “ICM20789”, “KELLERLD”, “LPS2XH”, “MS56XX”, “SPL06”, “AIRSPEED”, “CRSF”, “QUAD”], “git_hash_short”: “ad6bf648e9”}

1092

Hi Patrick,
so how did you configure it?
RC_PROTOCOL=23 and CRSF on the TBS RX side, do you receive regular CRSF telemetry as discoverable sensors on your radio?

1093

Hello Alex
I do receive standard telemetry of the receiver but not the flight controller data when using the Matek, all is good with the cube

1094

is RC working on the Matek at all?

1095

Yes it does , the NANO receiver is configured like this:

ch1 SBUS = connected to RC-IN (Usart 6 rx)
ch2 - not used
ch3- CRSF RX = Connected to USART 7 TX
ch4 - CRSF TX = Connected to USART 7 RX

1096

Ok, that won’t work, disable and disconnect sbus, use crsf only, set protocol 23 on the serial port connected to the crsf tx/rx lines. Custom telemetry works only over CRSF as RC protocol

1097

One last advice, CRSF pretty much requires a serial port with DMA or you will eventually run into issues.
BTW the setup you were using (SBUS + CRSF on different ports) is for controlling external devices via the CRSF protocol such as runcam cameras

1 Like
1098

Thanks Alex, it works.
My bad, I was really thinking that this could work in a mixed signal interface, but it is CRSF exclusively

1 Like
1099

Anybody had experienced that yaapu telemetry freezed while the normal telemetry coming from crsf rx and FC to the radio(TX16S Mark II) was continous?. I have lost my dji video signal coming back to home from 4.6km at around 3km and shortly after thatb yaapu script also stopped refreshing datas🤔 . Checking the edgetx telemetry log i not found any break in the telmetry values. ON the graph i marked with the blue crossing line where the video was gone and after that point the yaapu telmetry also freezed. I could switch to RTH showed by green line SF switch position and the plane was in RTH when video come back so RC control also worked during the video disconnection

FB_IMG_1665224354629
FB_IMG_16652243546291520×720 55.8 KB

FB_IMG_1665224358779
FB_IMG_16652243587792048×1536 301 KB

and yaapu freeze. The yaapu telemetry only came back after 30 -40seconds when the plane was at 1.5km and than i switched off RTH (the video also reconnected with the dji goggles). Unfortunately FC did not logged due to a bad sd card, so have only radio logs
FC: matek F405 wing with 4.4 custom build FW for canvas mode msp osd
So based on the radio log i cannot see any issue in the telemetry stream🤔
I only changed before this flight crsf rx UART 1 to 236K instead of 115k in MP…and the crsf module baud to 400k in the HW menu of TX16S. As i ve reqd uart 1 can work till 400k.
What can i check in the radio log which can show if it there was or not break in the telemetry stream around 3km ditance…is it possible yaapu script can freeze for short time in spite of the radio get all passthrough telemetry continosly.

1100

Hi, only thing I can think of is that CRSF dynamically throttled the telemetry rate to a very low one, the lowest rate is just too slow for passthrough telemetry so the effect would be a freeze of the screen.
Standard CRSF telemetry would keep flowing with updates like once per second.

1 Like
1101

Out of curiosity what version of EdgeTx are you using?