Frsky-X protocol

Hello all

I have deviation 5.0 and a banggood 4 in 1 installed in my Devo 10.
My question is that I cannot locate the Frsky-X protocol button when searching
thru the protocols on my Devo 10. I have the Frsky and the Frsky V8 button but that's it.
Am I missing something here?
All this has come about because I picked up one of those Frsky FX400R (clone/spinoff)
and my understanding is it uses the D16 protocol with telemetry which would be the Frsky-X protocol AFAIK.
Is this protocol not in the 5.0 release but in a newer "nightly" build?

Thanks

Ethan

You are right. FrskyX protocol was added some weeks after the release of 5.0. So you need to install the nightly builds to access FrskyX.

Thank you Ajtank

OK - Anyone have a nightly build with this protocol that they
can recommend that utilizes the telemetry option as well?

There was a recent FrskyX improvement by hexfet in July. So you may just pick the latest one in the download section.

If you haven't been running nightly builds, you might want to consider the 5.0.0 + new protocols build in www.deviationtx.com/forum/builds/6407-de...cols?start=220#64379 .

Vlad's builds actually are pretty much the same as nightlies except for the gui changes which only affect color models, so you might as well stick with the nightlies for your devo 10.

Ok - So I've downloaded Vlad's 5.0.0 + new protocols build but with the attached statement

"Firmware DFU file only, you can get other components from official v5.0.0 release."

I'm not sure how to proceed.

I've done the initial Deviationtx install and the upgrade to 5.0

I just don't want to screw with my Devo 10 until I can locate some clear instructions to

install this build.

Thanks for all your responses

Ethan

If you've already installed 5.0.0, then you can install the new version by just using dfuse (or the deviation installer. Do back up everything on the radio file system first, but that should be it.

The voice feature interferes with the currently by default enabled output of s. port telemetry to the serial port (ppm port). To handle this, the only reasonable solution seems to be a protocol option to enable or disable this output. Which behavior should I make the default one? It probably comes down to whether there are more s.port decoder or voice users.

No one has commented about the s.port output. I was considering just disabling it if extended audio was enabled. A protocol option would be a more flexible solution. I recommend it be disabled by default.