Passthrough telemetry over CRSF (crossfire)

OK. I have a Crossfire Nano soldered directly to TX6/RX6/4V5/G. I have Serial7 (UART6) set to 23; RC_IN. ALT_BRD_CONFIG needs to be set to 1, and make sure CSRF passthrough is added to the RC_OPTIONS flag. Once changes are made, reboot the board.

1 Like

Thanx I will give it a try. I see I don’t have ALT_BRD_CONFIG set to 1

@davidbitton can you post your parameter file here so I can double check if I have all the right values set?

setting that to 1 changes “TIM3_CH2 TIM3 RCININT FLOAT LOW” to “USART6_RX USART6 NODMA”

@yaapu
I have a weird issue, maybe you know something about it as it seems script related.

I see the sensor data when I look in the remote. Not only the crossfire related info like power, but also pitch, yaw, roll, altitude from the flight controller.

However on screen the artificial horizon on the remote from the script, and probably other values are not updating.
Is there a way to reset the script, or maybe there is something wrong with the config file?
Seems weird that the values in update in sensors, but the script does not seem to do anything (apart from the crossfire info)

Hi, the answer is quite simple, the script does not use sensors :slight_smile:
It uses CRSF telemetr to transport custom data as explained in the opening post.
I’d check 2 things:

  • make sure the RC_OPTIONS parameter has bit 8 set to 1, when set RC_OPTIONS values should be > 256, one simple way to set it is adding 256 to whatever value it already has
  • make sure you enabled CRSF support in the script config menu

No cannot get it to work… I’ve exhausted things I can try… I give up.

Hello,
I have been trying to find out a solution in order to have either LQ or RSSI working on CH12.
Both tried the nano/Micro v2 wired up as follow:
5V/G Ch1 to SBUS.
The failsafe works, it does get firstly in circle then RTL.

Would you suggest any alternative way?

Hi,
I managed to get Yappu Script working correctly this morning on 2 platforms following these steps.

  1. Ensure all sensors are reading on your radio. If you see around 20 or more sensors you’re good. CRSF will show the standard ones.
  2. As @yappu has already said ensure RC_options is 256 plus your original setting. For me it is 288 (32+256=288)
  3. I recommend copying the latest YAPPU script from https://github.com/yaapu/FrskyTelemetryScript just to be sure.
  4. Ensure to set the widget so that CRSF parameters are enabled
  5. Forget all sensors and then add them again.

Hopefully now it should work.

I tried this on:
ARDUplane 4.1.0 with a Kakute F7 mini
ARDUplane 4.1.0 with a Matek765

Hi Will, you need to select “min” as center and right panels, memory is so tight on x9d that I had to disable some UI features. You also need to power cycle the radio

Thanks Alex I did a search and found the info as well. Everything is working great now!

1 Like

Hey Josh,

I tried multiple version of firmware including both copter and plane to see if that made a difference. (dev and latest)
-I save the parameter file when it’s flashed fresh so I can revert back to default values.
-Did a full chip erase to make sure there are no left overs from previous installs.
-Always make sure to change 1 parameter each time and reboot the fc before moving on to make sure I dont loose track of where it went wrong.
-RC_options default for me is 32 so whenever CRSF works for rc in the fc I change that to 288 (32+256)
-I have the latest yaapu script, and the CRSF option is turned on. I also use the script in other configurations with an frsky reciever and it works fine there.
-Deleted all sensors and rediscover again
-Tried different uarts to see if that is the problem
-Tried with and without the Alternative BRD setting

My crossfire transmitter is at firmware version 4.11

I have 2 options left I’m at least going to try.

-reinstall the script in the transmitter
-I’m starting another plane build with a Matek 765, so will also try it with that FC

Got it to Work!

Damn I’m so stupid sometimes :slight_smile:

Was going through everything I tried until I realised that @davidbitton wrote that he set serial7
I set serial6 believing uart 6 on the board is serial 6 in mp.
Dough! should have knows from an older F4 setup that the uart numbers dont correspond with the serial numbers in mp!

phew… now I can sleep again :slight_smile:

1 Like

In 4.1 if you connect via mavproxy and do ftp get @SYS/uarts.txt - you can see both the uart and serial mapping

1 Like

@OldRaven nice to hear it worked. This page at Matek has become invaluable when it comes to setup.

http://www.mateksys.com/?portfolio=h743-slim#tab-id-5

It’s the mapping table between hardware resources and Ardupilot naming (UART6 -> Serial7)

1 Like

Ok, for the first time I’m having real trouble getting the script to work with an FC - although it should be mentioned right away that I’m not getting the full set of telemetry sensors in OpenTX either (only the first 10).

I have the widget set up just like on 4 other models, on all of which it works (3x F405-WING, 1xF405-CTR). CRSF is enabled, RC_OPTIONS set to 256+x, PROTOCOL is 23, RC by MAVLINK is off. And I just spend 2 hours moving the RX to a UART with DMA (lots of stuff was in the way) - no change.

The FC is a Holybro Kakute F7 V1.5 AIO which has DMA on UART/SERIAL 2.

Of course it’s suspicious that even though the script is not using sensors, those are missing too for some reason.

Is there anything I might have overlooked?

By the way, is the script compatible with Crossfire firmware 6.x which apparently intoduces “CRSF V3”? I’m still on 4.11 and don’t plan to upgrade anyway unless there is a benefit of some kind. Just asking.

Make sure you don’t have protocol 10 configured anywhere - this was @hwurzburg s problem

6.x should work fine although I find the binding a bit flaky at the moment. I have a PR to support CRSFv3 - which basically means more channels - but they are backwardly compatible

No protocol 10 anywhere unfortunately. I am now absolutely sure I had this working last November, as I found a video of the copter flying, and Yaapu voice messages can be heard on it. That was on UART1 (no DMA - and I had some failsafes back then, and a crash, so I wanted to move the RX to DMA anyway). This year, neither UART1 nor 2 work with Yaapu, and about 10 sensors are missing too.

Things that changed between November and now:

  • Updated AC dev
  • Updated Yaapu script
  • Updated Crossfire

The only thing left I can think of is trying the version of AC I used back then. I already tried 3 different recent versions, because a few months ago I came across a dev version of ArduPlane that somehow disabled Yaapu (although I didn’t check if half of the sensors were disabled too).

I also found this, but it’s obsolete now, isn’t it?

With this old version from October, both Yaapu and and all sensors started to work immediately:
arducopter-yaapu-crsf.apj (829.1 KB)

It’s the one I used during the final flights of 2020. It might even be a special version provided by Mr. Yaapu himself, as I didn’t add a date to the file name like I usually do (I always keep all the versions I ever used, to trace back problems like this).

So I guess there is hope, something must have changed in AP that prevents it from working for me.

sometime along the way we changed the frame IDs to compy with TBS firmware so If it works with older ardupilot and dose not with current master you might have a too old yaapu script/widget