New FrSkyX protocol

Official module installation documentation is here: deviationtx.com/links?task=weblink.go&id=28 If your installation doesn't agree with that, or you're confused about things, please ask for help before trying things. Blogs, forum posts, etc. are generally unmaintained, and may be outdated. They also tend to be for specific transmitters and rf modules. The official documentation is updated as things change, and tries to cover all models and rf modules - which can make it confusing.

Yes, if you want to use the FrSky protocol, you'll need to update to a nightly build.

I believe the issue with windows and the devo transmitters is driver issues, not the devention software. However, you can try the deviation installer and driver installer, both of which can be downloaded from deviationtx.com/downloads-new/category/161-dfu-usb-tool . I diid get them to work, but generally just use a Windows VM on my Unix desktop running an old version of Windows so avoided all those issues.

Mwm thanks for your help, and for your answer.
it was my way of thinking that the issue was a conflict between Win and deviation or Tx.. I have understood that yesterday PM (in France) and decided immediately to study linux.
I hope to succeed in this challenge.
it's perfectly unbearable to see the desertion of the "support" of Walkera and the devention "team".
But keep in mind that they are always here to sell devices "ready to use".
For some weeks maybe.
regards

Walkera has absolutely nothing to do with this. The Deviation software is a free project done by people in their spare time, none of them make a single cent off of this.

Hi arakon.
I am not speaking / hurling about deviation which is fantastic, marvellous to.
I said, i hold to, that Walkera is still selling most devices ( heli quadri aso) ready to use.
I dont know if devention is still present in their Tx. They are quite silents about that.
but the "old" one are always with devention.
So you / they need devoDFUSE usb Upgrader to upgrade these Tx.
Where can you find this program wich functionned without any problem with the most recent PC OS ?
So I Hold that Walkera, which has sold hundred and hundred Tx, is now far away of any support.
The same for devention.
Try the links to walkera.com and devention.
And if you succeed to open a Walkera web site, try to find any support about devoDfuse USB upgrader.
That's what i said.
Regards

mwm wrote: Yes, if you want to use the FrSky protocol, you'll need to update to a nightly build.

This is the D16 protocol isn't it please?

djdazzy wrote:

mwm wrote: Yes, if you want to use the FrSky protocol, you'll need to update to a nightly build.

This is the D16 protocol isn't it please?

Not available yet, but being worked on. IIRC, the old release doesn't have the D8 protocol.

mwm wrote: Not available yet, but being worked on. IIRC, the old release doesn't have the D8 protocol.

Thanks for confirming that mwm.

It is available in the protocol_combo test build, but telemetry is not implemented yet. Needs testing First to see if it binds, then to check the channel ordering and scaling.

The combo build also includes two fixes to frsky2way telemetry that I ran across while working on frskyx (more below). Looking at midelic's implementation and the opentx code revealed two issues with the deviation implementation: it doesn't handle telemetry data split across rf packets, and it depends on certain data elements being received in order. I've tried to fix that in the combo build. I did not look at the units conversions nor the display code. I also have no way to test this - time to finish my multimodule...

I found some captures on rcgroups that I thought I got to through a link in this thread, but now can't find it again. I'll post the info here but if anyone can point me to the rcgroups thread I'd like to put it there too.

The rx/tx "handshake" byte (tx byte 21, rx byte 5) seems to be forward/backward packet sequence numbers, plus a couple control bits. Both tx and rx put their sequence number in the 2 lsb of the high nibble. The two lsb of the low nibble is the sequence number of the last packet received successfully. Both ends start by sending 0x88, probably till the first packet is received. It looks like bits 6 and 7 are used for something as well, as they are occasionally set in the tx packets and the packet data looks different - setting failsafes maybe? Only saw one instance of bit 6 being set in a telemetry packet. The x4rsb_thr_up.spi.csv capture file has examples of all these packets.

Sequence numbers allow detection of dropped and duplicated packets. From the examples in the captures it looks like they're ignored for the packet data bytes - a packet received twice in a row with the same sequence numbers may have different embedded data (e.g. channel values, rx telemetry). But they do apply to the telemetry data stream, though I could find only one example. In the same capture file at 3.754516 the rx sends a telemetry packet with sequence numbers 22, which the tx acknowledges at 3.762821. But the rx misses that packet and so repeats the same sequence number, and repeats the valid telemetry data. The telemetry packet decoder can take advantage of these bytes, though ignoring them would just mean some missed telemetry updates.

The telemetry stream data in the rf packets seems to be the same as the serial wire protocol for both D8 and D16. If that's true the opentx code should be the best reference on interpreting telemetry data.

I can test this but which flavour of the D16 protocol is it please?
I am running the international version but there is also an EU and an EU-LBT version which aren't cross compatible.

@hexfet
If you find something useful ..see here.
www.rcgroups.com/forums/showthread.php?t=2503871

yes you caught exactly the telemetry problems on deviation with Frsky D8
for D8 hub telemetry see here
www.rcgroups.com/forums/showthread.php?t=2547257

@hexfet

Sorry I cannot get my X8R(int f/w) to bind in FrskyX mode on my 7e.

I had the crc wrong. Bind packets seem okay in the emulator now.

There's a new protocol_frskyx test build that includes the 7e. Thanks for testing!

I'm not sure what the difference in the EU versions might be.

Thanks Hexfet,

There is no frskyx.mod file in the protocol directory so I do not get the X protocol in menu.

I just downloaded the 7e zip and frskyx.mod is in there.

Is this the version you have? deviation-devo7e-v4.0.1-8dab7b3.zip There might have been an earlier version uploaded that was mixed up with the combo build, but it was only there for a few minutes...

Sorry my bad, downloaded incorrect version - [hexfet]protocol_frskyx is the correct one.
I have tested and can confirm I can bind to X8R in D16 mode. Receiver lock is intermittent whilst testing though. I get the green/red led flashing and it is not a swamping issue.

Tested channels 1 -4 and they do respond to input every 2s or so then they drop into failsafe in between.

I've updated the protocol_frsky test build. It should be better, or maybe worse. Think I found a couple mistakes in my translation.

Thanks for testing!

Hello, i try to help with Frsky x
TX Devo 8s, RX X8R, SBUS to PWM Decoder from Frsky ,Software: Latest Test Build for FrskyX , RX Firmware is International
RX are running with out Problems on Taranis with OpenTX ver. 1.X ( latest 1.x )

Range testet with 10 mW , detached TX Antenna : Through 3 Walls Rx Led does little Flicker
Cannel 1-8 on RX is running Direct and does good hitting the Point
Cannel 9-12 over the SBUS to PWM Decoder is a bit Bugy. Cannel 9 and 12 is Ok, like the Direct Outputs.
Cannel 10 is running left to 100 ok but on right it jumps from ca 75% on stick return to center
Cannel 11 is doing wild jumping with servo noise, same sound like wrong PWM speed setting on analog servos
-> on the Decoder the Cannel output light are the same, Cannel 9 and 12 all ok and on Cannel 10 and 11 all 4 lights are on ( may be a wrong Cannel sending to the Decoder ? for 10 and 11)

all tests with a servo connected to the Cannel outputs.
If You need more Info , i try to help.

greetings Alex

Definitely seems like a step in the right direction Thanks for testing!

Are channels 1-8 also good on SBUS?

I'll look at the problem with channels 10 and 11. Likely made a mistake in the byte-splitting of channels into the packet.

Hello,
Test with SBUS to PWM.
Cannel 1-4 are not doing any thing right, most short acting and noise with no real linear Stick movement. Some jumping to Stick position and some not moving with bussing .
Cannel 5-8 are moving ok with a litte noise like wrong speed on analog servos.

greetings Alex

Thanks Hexfet, looks good on the 7e with PWM.

Can you confirm which build this is forked from please?