Passthrough telemetry over CRSF (crossfire)

Development Team
564

Thanks Alex, it does, enough to understand the mavlink data not being available to scripts. I see that the place where this would be possible is if the Crossfire module took the MavLink data and made it available to OpenTX as part of those telemetry frames, just like they do their own sensor data. Unfortunately, the firmware running on the module is closed and I doubt that TBS would be interested in doing that. May be worth logging an enhancement request to them regardless since their modules run on mostly OpenTx radios.

This makes sense and helps understand the need for the setup with 2 UARTS; thanks a lot!

1 Like
565

Thanks @jimenezlee! The discussion you’ve been having here today has given me some insight to how I need to set this up.

I was able a while back ago to get the Yaapu script running on Crossfire, and before that I had MAVLink running for my GCS. But not together. Reading now that you need to use two UARTS is the clue I was missing.

The forecast this weekend is -25c and snow, so I think I’ll be tinkering with this.

2 Likes
566

i am also using a v1 TX and its working flawlessly and its mostly in RFMD 2 without any lag or getting stuck

1 Like
567

First of all, thank you very much @yaapu for investing so much time and effort in this community. I just got the Script running on my Horus x10. I got one major Problem and a tiny one.

First of all my Setup: Horus x10 with the full Crossfire TX, Crossfire Nano RX v2 and my FC is the Matek f405-Wing.

I was able to set up everything, I have all the Sensors (23), my horizon is moving, speed and alt is beeing displayed and also my GPS coordinates. So I dared to do the next step and tried to setup the maps (I am using the latest Yaapu script 1.9.3-beta2 and it runs great btw.). I followed step by step the awesome video from the Youtuber “Built from Home” on how to download the tiles using GMapCatcher and convert them to 100x100. But unfortunately after finding a Lock on the Gps my Horus ist just showing the NO MAP tiles.

So I went into Mission Planner, fetched tiles and convertet them using the tool you included in the TOOL directory in the new YAAPU 1.9.3-beta2 ZIP. So far so good, all files 100x100 but somehow .jpeg. Dragged them onto my SD, plugged into horus and still NO Map tiles. Arrow moves, it shows my home location but it just wont display the satellite tiles. My Settings in YAAPU CONFIG are DMS, Google, GoogleSatelliteMap, min zoom 1, max zoom 20 (it won’t let me change max/min zoom, I only have 2-18).

So yeah, thats my main Problem, the other one is, that my horizon is moving, but delayed and during rapid movements it laggs, is this normal or did I overlook something?

If you, or anyone else who maybe experienced the same problem, find time to help me with this, I would be very thankfull. I am going to record a detailed Video once I figure this all out on how to setup the whole system and will also post a link here.

Thank you very much in advance.

1 Like
568

UPDATE: I got it working! The problem was, beacause it wouldnt let me change the max zoom I was stuck at 20 times, but as soon as I zommed out the tiles would apear.

2 Likes
569

This isn’t field tested, but I’m declaring a win!

I have Yaapu telemetry working on my TX16S AND MAVLink to the Mission Planner on the laptop. I’ll share my setup info in case this helps someone else.

Matek F405-Std
Arducopter 4.1.0.dev
OpenTX2.3.11
Crossfire 4.10 beta on Micro TX V2 and RX Nano.

The laptop is connected directly to the Micro TX WiFi access point. I am not using a hotspot or any extra hardware. I’m hoping this will make it practical in the field. Yes, you need to restart the MAVLink UDP on each startup.

I’m using the 2 UART method described by @jimenezlee
Channel 1&2 on the RX are connected to TX/RX 4/Serial2 on the FC using CRSF. (I had started with this on TX/RX3, but the telemetry didn’t work so I moved to 4 and seems to work)
Channel 3&4 on the RX are connected to TX/RX 3/Serial1 on the FC using MAVLink.

I’ve tried both SERIAL1_PROTOCOL = 1 and now I’ve got it 2 (MAVLink 2).

I’ve only noticed one issue: The parameter loading on the GCS takes a long time. On Mavlink 1 it took about 25 minutes to load the parameters. I just tried with Mavlink2 and it was considerably less at about 8 minutes. Once the parameters are loaded things move along quick enough. There is some latency (it’s not an RFD900 link…) but it’s totally useable.

Any suggestions to improve the parameter loading time?

6 Likes
570

Hello.
Have some questions.
Matek H743 Wing

loaded 4.1
commit 164da26
Author: Peter Barker pbarker@barker.dropbear.id.au
Date: Sun Feb 7 08:20:57 2021 +1100

Have done some testing for Andy piper on soft brick issue. Matek H743 Soft Brick · Issue #16202 · ArduPilot/ardupilot (github.com)

So while 4.1 loaded I would like to try Yaapu pass through CRSF telemetry.

uart2/ serial 3 set to rcin, rx crsf all working basic opentx telemetry and RC control. opentx FM sensor is showing qstab which is mode on discovery and does not change( not armed yet)

messages I think debug
07/02/2021 16:27:22 : CRSF: RF mode 2, rate is 186Hz
07/02/2021 16:27:17 : CRSF: RF mode 1, rate is 179Hz
07/02/2021 16:26:58 : CRSF: RF mode 2, rate is 183Hz
07/02/2021 16:26:53 : CRSF: RF mode 1, rate is 182Hz
07/02/2021 16:26:38 : CRSF: RF mode 2, rate is 182Hz
07/02/2021 16:26:33 : CRSF: RF mode 1, rate is 185Hz
07/02/2021 16:26:25 : CRSF: RF mode 2, rate is 194Hz
07/02/2021 16:26:20 : CRSF: RF mode 1, rate is 193Hz
07/02/2021 16:26:03 : CRSF: RF mode 2, rate is 175Hz
07/02/2021 16:25:58 : CRSF: RF mode 1, rate is 181Hz
07/02/2021 16:25:53 : CRSF: RF mode 2, rate is 189Hz
and more …

I would expect mode 2 to be much lower ??

Does this commit 164da26 include the Yaapu customized code for pass through crsf. ie setiing rc_options. If not is it safe to fly using the latest 4.1 Yappu customization and what commit is customisation based…

Is it possible to stop above messages, they flood OSD while flying FPV.

Is there a list of Uart/serial that have DMA for Matek H743 Wing

Thanks every body Stay safe.

1 Like
571

I would expect Mode 2 to be 150 and Mode 1 to b2 50 - it does seem wrong.

That commit includes CRSF passthru.

You can’t turn it off, but then you shouldn’t be getting it every 5s - so seems like something is wrong. Turning it off may not be a bad idea though - we probably should display the rate in the OSD instead.

1 Like
572

Thanks,

Will give passthrough a go, with test flight.

If I can help with any testing please let me know.

Cheers

1 Like
573

Hi Philip, locked zoom min/max is indeed a bug, thanks for reporting!

1 Like
574

Yeah, it’s verbose but not that verbose, adding OSD support for CRSF would be nice, RSSI and RFMODE :slight_smile:

1 Like
575

RSSI works already I think?

1 Like
576

Ah! Could be, didn’t check, how about TQly and RQly, probably missing

1 Like
577

Hi All

RSSI works in osd – rssi type 3 rx protocol

can also put RSSI RSSI/RQ or RQ on a rc channel in tbs rx channel config. Then pic up with rssi type 3 and RSSI_CHannel set to sane channel as RX config. Then RSSI in OSD shows chosen value.

First flight today
open tx 2.3.11
Yaapu 1.9.3 beta 2
arduplane 4.1 commit [164da26]
Matek H743 wing.
Jumper T16.

The telemetry script stops working occasionally with red disabled message.

While active telemetry is working well.

The messages RF mode etc are much less when flying. I think the overload of messages is indoors when tx and rx are close. Mode constantly changing (RFMD 2 or 1 constantly switching) and low RSSI

What logging do I need to switch on to trace

Cheers

2 Likes
578

How about data throughput with both CRFS and MavLink ? I would guess MavLink will take up big portion of bandwidth, sacrificing Yaapu’s CRSF Passthrough messages rate.

1 Like
579

Any suggestions to improve the parameter loading time?

Some connection types are able to use MavFTP to load all parameters in a stream without a need to query every single one. However, for some reason, unknown to me, MavFTP is not used for Crossfire MavLink connection. Maybe @andyp1per will have some knowledge about this?

1 Like
580

Personally I would set very low rates for mavlink telemetry and quite high rates for parameters, this to allow for smooth CRSF passthrough telemetry, decent mavlink telemetry which would be a sort of backup and log facility and pretty good parameters download. If telemetry stutters while downloading them is not a big deal IMO, I will probably be on the ground anyway

1 Like
581

aggresor2-20210209_115220_plog.lua (130 Bytes)

I have uploaded this log , current when yaapu widget stopped with blank screen and red letters — DISABLED.renamed .plog to _plog.lua to upload. Not sure much in there !!!

I have 5 opentx widget screen active, will close all but yaapu widget and do some flying.

582

can you access the widget yaapu settings page, it should show you some more info. How did you produce that log? Current beta version should not create debug files, if you’re using a debug version it may very well crash the widget

583

A few minutes, sure I can deal with that. But 25 minutes was too much. In most cases the flight would be over.