New FrSkyX protocol

hexfet wrote: I've created an frskyx_drop test build that has a protocol option to disable the packet sequence number counter. Please check if there's any difference in dropouts between the off and on settings. Thanks!

Not sure if this is any help for you but I still get dropouts with X4RSB and 3 in 1 module installed in devo 10. With sequence option turned off in your test build.

hexfet wrote: Don't see this issue in the emulator. Does it happen with other protocols?

Did you upgrade your filesystem when changing from 4.0.1 to 5.0.0?

Please, can you tell me how to do that ? Is that ok ?
Full installation instructions:
To install when current firmware is Devention:

* Download the firmware dfu for your transmitter and the 'filesystem' zip file
* Unzip the 'filesystem' zip file
* Install firmware dfu for your transmitter
* Restart transmitter.
* Windows should ask to format the drive. press 'Ok' to format
* Open the new 'Removable Drive' in Windows explorer
* Copy the contents of the 'filesystem' directory to the 'Removable drive'. Do NOT copy the directory itself!.


I have trouble with an XSR mounted on my quad, i have a crash, and i first expect my betaflight settings.
This morning i've done a test and about 2 mins, my drone fall down a sec et come back normally
Maybe this can help to understanding ?

I use a new model to create
Thank you.

Getting random drop-outs on Devo10, CC2500, Test-firmware(19-JUL-2016) and a X4R-SB, Failsafe set to RX

But don't got any data to back it up.

It happends at about 50-150+ meters range on 100mW

i have the DEVO with CC2500 too, work it better with an all in one module ?
What can i do for helping resolve the drop outs ?

Thank you

Whether can consider to make the DEVO 7E can give mobile phone or PC Output telemetry data via a USB connection？like as in the case of output HID handle pattern。

hy all,
i have devo8s with xsr receiver and i have random dropout too.... i have a cc2500 and no issue with other protocols i use with it (devo dsm2/x and frskyd8)

if it can help finding solution

test with and without failsafe set

Until the problem is solved with the xsr, what s-bus receiver with decent range (600-800m) can i buy ?
is the D4R-II a good choice in PPM ?

Thank you

D4R-II works just fine. I'm using one of the earlier frskyx test builds and have absolutely no issues or dropouts on both an XSR and an X4R-SB.

I don't suppose you still have the test build zip folder you could hook me up with arakon

D4R-II with older nightly works fine for me, Telemetry is working with Voltage1/2 and RSSI. Got a X4R-SB now, but not testet yet. According to the the Manual PPM for 8 channels also should be possible.

Arakon wrote: D4R-II works just fine. I'm using one of the earlier frskyx test builds and have absolutely no issues or dropouts on both an XSR and an X4R-SB.

Evans wrote: I don't suppose you still have the test build zip folder you could hook me up with arakon

It would be great

Smarti wrote: D4R-II with older nightly works fine for me, Telemetry is working with Voltage1/2 and RSSI. Got a X4R-SB now, but not testet yet. According to the the Manual PPM for 8 channels also should be possible.

The D4R-II and that telemetry also works fine in the 5.0.0 release, since it just uses the FrSky protocol that was in that release. Hub telemetry was present, but badly broken. When you switch to a build with the FrSky X protocol, the telemetry was reworked as the two have a lot of common code, and hopefully we'll get the hub telemetry (though FrSky X doesn't use a hub) working in it when all is said and done.

Hello,
I also have an XSR receiver, with a Devo 7E and the 5x nightly from 3 days ago flashed on the transmitter. I also use the CC2500 module.

Did not experience dropouts so far, but I haven't flown a lot. I did notice though that telemetry does not work very well and wondered why. I expect to get RSSI, and both voltages since I don't have the CPU mod on the Devo 7E.
Instead I <sometimes> get the first voltage, never got the second voltage, and my RSSI looks flips from "29d" to "109d" intermittently instead of showing something gradual.
Just wondered if I'm doing something wrong or if there's a bug/something I could help test to make things better.

Thanks a lot of the FrSkyX support by the way!

i fly three days a week and stay with 4.01 as i found version 5, other than the FrSkyX, did have occasion drop out on some of the protocols.

cmPang

Unfortunately, I only have the "ultimate 7e" build anymore.
This test build says 4.0.1, but was actually based on 5.0 already, I believe.

Thanks for all the reports. Appreciate the testing and wish I wasn't so busy with work.

I've rebuilt the 070e55e commit and uploaded to the frskyx_drop test build. Didn't seem like subsequent changes would have broken anything, but maybe.

The blackbox log looks like a complete loss of signal. sfersystem, is it possible to also log the channel values from the receiver?

Thank you for working on it Hexfet, but I had not activated at that time unfortunately.
I mount a D4R-II now that seem to work, but if u need more test with the XSR and all datas, it should be possible. tell me.

hi hexfet,
to inform you that i just try the rebuilt of the 070e55e drop test build on my 8s and i still have dropout

I understand from the Beta flight project, it is recommended to put your Taranis X protocol setup into 8channel mode instead of 16channel, this halves the latency or refresh rate on the data, which is better for the pid controller as no smoothing on rc input is needed. Do we have looked into the option to set to 8 or 16 channels mode in deviation?

Fernandez wrote: Do we have looked into the option to set to 8 or 16 channels mode in deviation?

It's not necessary. If the number of channels is set to 8 or less then it operates in "8 channel mode", which just repeats the lower channel values in the upper channel timeslots.

In fact for FrskyX any unused upper channels will be filled with the lower channel values. So if you have 10 channels enabled, channels 3-8 will still run in "low-latency mode".