No sbus in 2.8.x but no telemetry in 2.9.x

[clemtrinc]

Is there an existing issue for this problem?

• I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Transmitter firmware

Current Behavior

Sbus output for external module(rfd900) not working in 2.8.x

When flashing 2.9 RC1 Sbus output is working but all telemetry data is lost and no telemetry communication.

Expected Behavior

Should be avle to get telemetry in 2.9 like it was working in previous stable versions

Steps To Reproduce

Flash 2.9 RC1, telemetry data fed to Yappu telemetry script is not getting received as it was in previous stable versions

Version

2.9.0

Transmitter

Radiomaster TX16S / TX16SMK2

Operating System (OS)

No response

OS Version

No response

Anything else?

No response

[raphaelcoeffic]

How are the telemetry data fed back to ETX? I don't think we have telemetry directly supported for SBUS modules (no std protocol).

[clemtrinc]

telemetry is sent via the Sport pin, it's mavlink telemetry which is decoded with a script, basically it's on a different independant line than Sbus.

[raphaelcoeffic]

@clemtrinc Can you please upload/point me at this LUA script? I have no idea how this was/is supposed to work, as we don't enable any telemetry for SBUS protocol. Maybe this was a "hidden feature" nobody knew about....

[clemtrinc]

Hi, https://github.com/yaapu/FrskyTelemetryScript
This is the telemetry script used.
But do you mean telemetry via the S.port pin of the external module is not enabled when using Sbus ?
Because the telemetry is driven via a different cable/protocol to the radio. Sbus and telemetry are two very distinctive things on my long range receiver's side.
Thanks

[raphaelcoeffic]

But do you mean telemetry via the S.port pin of the external module is not enabled when using Sbus ?

Well, it's not, as there is normally no telemetry protocol used for SBUS modules. S.PORT might have been enabled by default in the past, but not really as a feature, probably more because some default was needed.

Because the telemetry is driven via a different cable/protocol to the radio. Sbus and telemetry are two very distinctive things on my long range receiver's side.

I see. But as a matter of fact, and from our point of view, you have a module driven by SBUS, and telemetry is received on the S.PORT pin, right? Is that something specific to that particular module, or is the telemetry coming some totally different part/module?

[clemtrinc]

But do you mean telemetry via the S.port pin of the external module is not enabled when using Sbus ?

Well, it's not, as there is normally no telemetry protocol used for SBUS modules. S.PORT might have been enabled by default in the past, but not really as a feature, probably more because some default was needed.

Because the telemetry is driven via a different cable/protocol to the radio. Sbus and telemetry are two very distinctive things on my long range receiver's side.

I see. But as a matter of fact, and from our point of view, you have a module driven by SBUS, and telemetry is received on the S.PORT pin, right? Is that something specific to that particular module, or is the telemetry coming some totally different part/module?

Interesting, it's a shame because this is a very popular script in the INAV community, especially when migrating from a taranis radio.

Basically the long range module takes care of sbus and telemetry, the telemetry is converted in a mavlink simplified data inside the long range module and sent via the S.port pin of the external bay and then interpreted by the script.
This is common with other long range systems like dragonlink etc.

Is there a way to compile opentx with telemetry enabled when using external sbus maybe ?

[raphaelcoeffic]

@clemtrinc no worry, we should have a patch to re-enable this very soon. The issue was: I was not aware of the use-case, and your issue was basically the first to point this out.

[raphaelcoeffic]

@clemtrinc in case you feel adventurous, you can test #3986 and report 🤞

[clemtrinc]

I did feel adventurous but unfortunately it didn't work.
I'm back at the same situation, the custom branch you built gives me telemetry with no issues but sbus is not going through.
I then updated to 2.9 Providence (latest released yesterday) and Sbus is going through but the telemetry isn't...
No idea what's going on, all woks well on two taranis, I need to get my hands on a second TX16S to try.

[raphaelcoeffic]

I did feel adventurous but unfortunately it didn't work.

You might want to check with @rotorman and join our discord server so we can debug. He claimed it worked for him.

[raphaelcoeffic]

sbus is not going through

Wait a sec: SBUS is not working properly on #3986 ? Now this is quite funky (the PR is based off the same 2.9.0 code....)

[clemtrinc]

Yes, but it also never did on 2.8.x for me. Only when I tried flashing 2.9RC2 at the time did I make Sbus working, but at the cost of telemetry not working on 2.9
The only way I get things working right now is with PPM and telemetry on on 2.8.X

[rotorman]

Just tested again with Dragonlink and in addition also checked S.BUS output of JR-Bay on TX16S with a logic analyzer.
I see no issues with PR #3986 - incoming telemetry via S.PORT gets parsed, as well as channel data output via S.BUS.

[clemtrinc]

Yes. I guess RFD is being picky with the SBUS signal, as I've read other people having the same issue.
I just wonder what is so different with EdgeTx 2.9 that it works but telemetry is lost...

[raphaelcoeffic]

telemetry is lost

This is easy: without mentioned PR, telemetry receiving is not turned on. It is now specific to the module protocol, which it was not in 2.8.x. The reason for that is that we are moving now to be able to receive different telemetry protocols in parallel when 2 different modules are used.

[clemtrinc]

ned PR, telemetry receiving is not turned on. It is now specific to the module protocol, which it was not in 2.8.x. The reason for that is that we are moving now to be able to receive different telemetry protocols in parallel when 2 different modules are used.

Yes, but in my case I am getting telemetry in 2.8.x before the PR, just not the Sbus signal going through( but set on in the external module parameters).
I'd need to check with an oscillator to see if Sbus is actually outbound the radio