New FrSkyX protocol

Thanks for the reply Hexfet. I've since replaced the CC2500 with another CC2500 module, and the Devo 10 is now functioning normally.

With the broken CC2500, the dropouts were occurring on the tabletop even with reduced Tx output power. The dropouts were pretty random and would happen once every few minutes. Changing the Fine freq didn't make a difference either.

Hi hexfet I'm also having drop outs for no apparent reason so have done some testing on the bench to see if I could replicate it and I've managed to and have the datalog with the failsafe set to hold also the datalog with the failsafe set to no pulse both with dropouts,I also have the datalog with the failsafe set to rx but it did not dropout set to this so don't know if it solves the problem or coincidence.
My set up is devo 6s
Frsky xsr receiver on a quad running betaflight
I didn't know weather the datalogs would be of use to you but I will post them tonight then you can take a look if you want to
Thanks for all your and everyone's hard work it's amazing what you have and continue to acheive

hi i dont know if this will work ive put them in a zip file.they will need the .nopulse/.rx etc removing

Thanks! I see there's data in the files but the datalog2csv script doesn't see it. Haven't had time to track down the issue.

It is significant that you did not see dropouts with the failsafe protocol option set to RX. With this setting no failsafe packets are sent at all, which suggests there may be an issue with the failsafe packet algorithm. Can you confirm that you never see a dropout issue with RX, so we know it wasn't just happenstance on one test?

Would you please check if the dropout behavior (with option at Hold or NoPulses) changes if the number of channels is set to 8 or less?

Have you tried different values for the Fine protocol option? It's probably unrelated but it's a possibility.

I will do some more tests over the weekend then hexfet and let you know
Thanks

hi hexfet
managed to get some flight time today and the drop outs continued to happen with failsafe set to rx this time and also happened with channels set to 8 and under with failsafe set to hold,i also flew with fine freq set to 10 and -10 and the drop outs still occurred.is there anyway of disableing telemetry to see if the problem is with telemetry or the control protocol its self

No way to disable telemetry at the moment. I could add an option for testing next week. But the protocol does not care if telemetry is received or not.

You might try some larger values for the frequency adjustment. The limits are 127.

I'll be able to look at the datalogs next week. You might try setting an alarm on RSSI telemetry if you haven't already.

Any other readers with an XSR receiver that can share their experience?

I have already got rssi active.i will do some more tests with more and less fine freq

Not sure if it is the right topic, but this could be nice feature for deviation. Basically ability to assign the received RSSI onto a servo channel.
Cleanflight is able to use RSSI from servo channel and then can be shown for instance on minimosd connected to flight control. It mean only an sbus link from RX to flight control.

Example video is here:

Quite nice feature

the guy in the video called it "straight forward"

Oh sure it's straightforward to setup and taranis the problem is what is happening...
So what's happening is that open TX takes the RSSI signal from telemetry and uses that to create what devo would call a virtual channel and then send it back to the rx as a channek. RSSI that's going in CF is lagging probably several milliseconds behind, if not more and secondly the numbers going into cleanflight are not actually the RSSI of the receiver at all, it is a number which is being created in the transmitter by reading another value so there's nothing to say that it actually has to be right, any number of things could go wrong and that number that showing could potentially not mean anything at all... Really not a good way to do it when the receiver has a dedicated RSSI output that just needs one more wire.

The best way, would be open RX, flashable open firmware on receiver, deviation rx software Have a full open source link.
If RSSI is available in the RX, theoretically RX firmware could forward it direct on a dedicated SBus channel.

My 10year old Nomadio radio I use for surface, shows 2 RSSI nr's at the TX.
RSSI, signal strength of received packets the RX.
RSSI, signal strength of received packets at the TX.

I have my Devo 10 binded to my Frsky xsr, but I cannot get the stick movements in cleanflight.
Currently on latest nightly build. Must the receiver be flashed for this to work? As mine is still stock.

Solved. Watched this video. Everything was made clear

Hello Gurus!

First off, my many thanks for this amazing job you folks are doing. You rock!

Noob here, first built based on many hours of reading, please forgive me if the question has been answered and please point me where it was. Got a SP Racing F3 running CleanFlight 1.13 (tried also with INav 1.1), a FrSky XSR and a Devo 7e with a CC2500. Maiden flight successful using the latest nightly build. Possibly I missed something somewhere, but I do not seem to be getting telemetry, as I can only see RSSI and VBAT1 (which is what comes from the receiver itself). However, I don't get the option to see any of the telemetry coming from the SPRF3 (mostly interested in the LiPo voltage). Is this because I need to convert my Devo 7e to Ultimate (bigger MCU) or because I am missing a setting somewhere? In this post, it is mentioned that I need to see TelemVAmp to at least see the model's battery voltage (which I see in the GUI) but the option is not displayed anywhere in my transmitter.

Thank you all for both your upcoming reply and the wonderful job that is being done here!

You are getting telemetry, but on the 128k processors like the 7e, the external sensors aren't available. So all you're going to get is RSSI and possibly two voltages. The XSR only has one of the two voltage sensors, so you're seeing all there is. The 256k CPU upgrade should get the rest.

If all you want is that second voltage, an X4R might be a better upgrade alternative.

ceskquad wrote: Hello Gurus!

First off, my many thanks for this amazing job you folks are doing. You rock!

Thank you all for both your upcoming reply and the wonderful job that is being done here!

Hey ceskquad, besides the telemetry issue how's the XSR working for you with Deviation? I would love to use my Devo F7/CC2500 configured on my new RX122 Atom with an XSR Rx. Are getting the dropouts and such? How about approx range? Thanks

Thanks mwn!

I will go for the stm32f103ret6. That way I can be ready for the next versions and get all the goodies. At least I know now I did nothing wrong ☺