Hi all,
I'm looking for people with a deviation transmitter and a FC with cc2500 spi (such as crazybeef3/f4 and matek411-one) to beta test a new protocol I've been working on.

This new protocol is roughly 5x lower latency then crossfire and 7-10x lower than taranis with frsky_X.

I've been flying this protocol that I wrote since about Oct. The purpose was to see how low of latency and fast of data rate I could push it. No telemetry for now. It is based roughly on frsky_x (to help with code reuse).

Support is currently with deviationTx transmitters and FC with spi cc2500 chips (Crazybee, Matek411RX, couple others). Looking at a multimodule version as well, but figured I would start here.

Flying really stable at 1.5ms loop time (666Hz). RC looptime and packetsize is adjustable (on deviation menus) for testing for now. Pushed it higher up to 1ms/1kHz rate, but ran into deviation cpu limits (and maybe BF not getting to the spi RX code fast enough always)

Latency results are awesome. 1-5ms from transmitter gimbal to betaflight dshot motor output. Compared to 7-20ms with crossfire on taranis and 18-37ms with frsky_x to X4r on a taranis. Hopping back to my taranis and you can really feel the difference.

4 11-bit channels and 12 1-bit aux channels. Total RC packet squashed down to 12-14 bytes. Although that could be bumped up if needed for anything.

I'll fully write up the protocol when it is pulled in any everything set in stone.

Range is still pretty good even though the cc2500 bitrate was bumped up. I lose RX on a crazybeef3 (no pa/lna) at about the range of 25mw VTx. Matek411rx with pa/lna, I get plently of range to cover any racetrack so far.

The higher rate also allows RC filtering to happen with only a slight amount of extra delay.

Couple things left that I was looking at:
I'd like to generate the pseudo-random hop_data based of the get_tx_id()/MCU_SerialNumber. That shouldn't affect this betaflight PR.

I was considering a slow bitrate option through a deviation menu option. Long range, higher latency. Not dynamic switching but able to switch to slow mode while disarmed. This could come as a separate PR.

Other Things:
Currently not support XSR/X4R etc. They have the potential to be added through opensky (https://github.com/fishpepper/OpenSky) but that would require some major work.

Not support natively on a Taranis. Even though the OpenTX is open source, the transceiver board on there contains frsky proprietary code. Support could be added though a multimodule plugged in on the back.

Betaflight PR:
https://github.com/betaflight/betaflight/pull/7601

Deviation PR: https://github.com/DeviationTX/deviation/pull/557

Download test files:
https://drive.google.com/drive/folde...kD?usp=sharing

Watching with interest Bryce

nicr work . do you modifi protocol on multiprotocol ?

Very nice work! Appreciated your tests in DeviationTX forums and watched with interest.

BF starts to reach Silverware's low latency now

Nice, follow with interest, embedded RX I believe is the future, less components less weight, less troubles.....
And finally a true open source, from start to end, inc the RF link, so developments and improvements can be made and flashing is simple.

I hope in the future, we not anymore need, to define our arms switches and channels etc in Betaflight, but all defenitions and setup to be done Tx configuration, Betaflight just receive the ïnstruction and will excecute. So in Tx we select a switch and we define , choose from a command loaded template f.i. "Betaflight" What each switch has to do. ARM, BUZZ etc.



But why in the graph, Deviation Frsky-X green curve has a better latency than Deviation Frsky-X SPI red curve?

I can test it with crazybeef3fr and t8sg v2 plus.

Originally Posted by John michel

nicr work . do you modifi protocol on multiprotocol ?

Yes multiprotocol is on the list. I wanted to get a couple people test with deviation first to make sure there aren't any issues before adding a 3rd code base into the mix.

Originally Posted by SirDomsen

Very nice work! Appreciated your tests in DeviationTX forums and watched with interest.

BF starts to reach Silverware's low latency now

Actually if you are talking bayang protocol, this is probably faster now. Deviation previously was running the ADC sampling/mixer every 5ms, so you'd get a 0-5ms delay in every packet. Some of the protocols have been converted over to use a different method that does the mix right before sending it out, but bayang hasn't been converted yet. Don't get me wrong, my betalite silverware board is my favorite of brushed whoops!

Originally Posted by fernandez

Nice, follow with interest, embedded RX I believe is the future, less components less weight, less troubles.....
And finally a true open source, from start to end, inc the RF link, so developments and improvements can be made and flashing is simple.

I hope in the future, we not anymore need, to define our arms switches and channels etc in Betaflight, but all defenitions and setup to be done Tx configuration, Betaflight just receive the ïnstruction and will excecute. So in Tx we select a switch and we define , choose from a command loaded template f.i. "Betaflight" What each switch has to do. ARM, BUZZ etc.



But why in the graph, Deviation Frsky-X green curve has a better latency than Deviation Frsky-X SPI red curve?

I don't think we will get away from setting up channels and switches in betaflight anytime soon. Each new betaflight mode would need a new mode setup in deviation, it would be hard to keep the two code bases synced up all the time.

As for the graph, that was a older version of deviation that didn't have the mixer syncing and I was using a switch to cause the throttle to go up for the test, instead of attaching my arb generator directly to the gimbal. Both of those slowed it down. I should have documented that test a little more...

Originally Posted by Phoboss

I can test it with crazybeef3fr and t8sg v2 plus.

Thanks! I should have test files for both of those here:

Download test files:
https://drive.google.com/drive/folde...kD?usp=sharing

I should document the binary switches. In short, each channel is on or off. The way I have it setup in deviation is when a switch is up I have it high on one channel. When it is low it is high on another channel. When in the middle it is low on both channels.

Different from a taranis where low, middle, high are all on one channel.

I'll get to documenting that more in the next couple days.

Just flashed my stuff with your files, thanks!

Enabled by setting:
set rx_spi_protocol=REDPINE
save

Is it normal that I have packetloss when connected to bf configurator?

EDIT: nevermind, when I leave bf configurator it no longer flashes and the lights are solid.
Gonna test fly soon.

Yup you got it!

I don't think you'll have to rebind right now because I'm using the same bind params as frsky, but that will likely change when I get the channel hop generation changed.

Yes packet loss is normal especially on the F3 board with the configurator, the USB and RX fight for timing...

OK, so I did some testing and so far so good, range is okay but I fly in a small apartment. I even tested with 100uw setting, and had no failsafes yet. Latency improvement is not noticeable at first, but when I went back to original frsky I could feel the difference.

I don't really need telemetry, I get all the info via OSD anyway

FWIW I gave this a shot and was unable to get it working... its hard for me to understand what is going wrong exactly:

With supplied test binaries for T8SGv2Plus and CrazybeeF4Pro if I set both to FrskyX I can bind and setup works. If I then switch both to Redpine it doesn't 'just work'... which I believe it is expected to just work, without needing to rebind.

With both in Redpine mode the LEDs on crazybee flash quickly, the no signal found flash.

While rebinding is not supposed to be needed, trying to bind while both are in Redpine mode sorta seems like it works.. maybe?

If I put crazybee in bind mode the leds go solid or whatever it is waiting for bind from transmitter... and it'll just sit there 'forver' in that state waiting.

The instant I enter bind mode on transmitter the crazybee reacts, seemingly exiting bind mode and going back to regular operation.. but despite binding working(?) when it goes back to regular operation it immedaitely goes to the fast flash, no signal found.

I'm unsure how to troubleshoot whats going on.

Originally Posted by bexamous

FWIW I gave this a shot and was unable to get it working... its hard for me to understand what is going wrong exactly:

With supplied test binaries for T8SGv2Plus and CrazybeeF4Pro if I set both to FrskyX I can bind and setup works. If I then switch both to Redpine it doesn't 'just work'... which I believe it is expected to just work, without needing to rebind.

With both in Redpine mode the LEDs on crazybee flash quickly, the no signal found flash.

While rebinding is not supposed to be needed, trying to bind while both are in Redpine mode sorta seems like it works.. maybe?

If I put crazybee in bind mode the leds go solid or whatever it is waiting for bind from transmitter... and it'll just sit there 'forver' in that state waiting.

The instant I enter bind mode on transmitter the crazybee reacts, seemingly exiting bind mode and going back to regular operation.. but despite binding working(?) when it goes back to regular operation it immedaitely goes to the fast flash, no signal found.

I'm unsure how to troubleshoot whats going on.

Hey Bexamous,
Thanks for the report. I'll run through the setup and see if I can reproduce that.

I also have a newer version that will be uploaded soon that will require a rebind based on some suggestions from other people (Increasing channel width). Also got the hop channels set up the way I want, It was using a static set of hop channels that was the same as frsky_X, but now it will use a pseudo-random set based off of the transmitter.

I'll also do a quick video showing my setup to see if that helps. I'm on a work trip right now, so I am trying to squeeze a little bit in here and there, but it has been busy...

Originally Posted by Phoboss

OK, so I did some testing and so far so good, range is okay but I fly in a small apartment. I even tested with 100uw setting, and had no failsafes yet. Latency improvement is not noticeable at first, but when I went back to original frsky I could feel the difference.

I don't really need telemetry, I get all the info via OSD anyway

Thanks for trying it out! If you want to see packet loss info you can debug_mode to frsky_rx_spi (can't recall the exact name right now). You can turn that on to display in the OSD. 1st item is RC looptime. 3rd is how many missed packets in a row (Shows 1 when getting a packet each time). 4th is packet size.

Ooops, was going to offer to test with omnibusF4 but forgot about the spi rx on board. (doh).

Great project, looking forward to it making it into Deviation and BF.