Redpine cc2500 - Trying for the lowest latency

Hi All,
I am been working on a proof of concept protocol to see how low I could drive RC latency with cc2500 chip. This is based of frsky_X and the work hexfet did with that. I bumped up the cc2500 speed to 250khz and reduced the packet size by about 1/3. 4 analog and 12 binary channel. Also the no telemetry currently.

Currently my testing has been 1.4ms between packets. I'd like to get it to 1ms - just because that is a nice round number and 1kHz update speed.

I'd like to implement a fast protocol - this one I am working on - and a slow protocol that goes for the best range possible (probably bring the modem down to 2.4kHz speed.

Here was the current latency tests with the protocol
docs.google.com/spreadsheets/d/1MlGdLWIP...g/edit#gid=891788793

The latency is defined as the time to get from a stick movement in on the transmitter to the motor outputs in betaflight

Currently at 2-3ms - Compared to 7-17ms with hexfets frsky_x latency test fix and 16-35ms in opentx.

The only hardware supported right now is deviation for the TX, although the multimodule should be able to be supported. For the RX only these FCs are supported: (because they have a spi cc2500 chip onboard) crazybeef3FR and matek-411rx.

deviation: github.com/brycedjohnson/deviation/tree/redpine2

betaflight: github.com/brycedjohnson/betaflight/tree/redpine1

Looking for a little feedback, or ways to improve!

Interesting reading Good to explore what's possible.

What model file are you using for the latency measurements? The attached "max mixers" model has 103 mixers on 16 channels. Curious if this changes the measurements at all. If it causes issues maybe could have the protocol check number of mixers and adjust looptime accordingly.

Also wondering why the latency variation in these measurements is much lower than the others. Do the betaflight changes make any difference in the "serial input to motor output" delay? For example with FrskyX the max delay from input change to packet send (in the test code) should be about 11 ms. The difference between that and the measured max of 17 ms should be delays in the receiver and betaflight - about 6 ms. But that same variation doesn't show in the redpine measurements.

Have you considered measuring the delay to receiver output instead of motor output? Both numbers are useful but the delay at receiver output would eliminate variations in delay through betaflight.

Also the FrSkyX latency with OpenTX and MPM must be done with the proper version since OpenTX was first implemented with a 22 ms transmission to MPM which would match what you see.
Right now the latency between radio to MPM is 7ms with ersky9x and 9ms with OpenTX. FrSky X transmits every 9ms so you end up with 7 to 7+9=16ms delay or 9 to 18ms depending if you've just missed the train or not.

For the model file, it is pretty dead simple. Attached the file. It says frsky_x, but I swapping between the two when testing. I'm sure adding in a bunch of mixes might cause issues. I wanted to make the packet rate flexible, so that can be adjusted in the options of the protocol. I was attempting to have betaflight attempt to sync to any packet rate, but I didn't quite get that working, so it is a fixed parameter right now (1.4ms).

For the difference in the delay, That is from a difference in the actual time over the air. For frsky_x I think I remember it 4.5ms-5ms to receive the whole packet (At a rate rate 30kbps?) For redpine I bumped up the rate to 250kbps and dropped the packet size down, so a ballpark guess is that the over the air time is at least 1/10 the time.

As an example with frsky_x with my hack in. The very best latency I had was 6.0ms where everything lines up perfectly. About 4.5ms or 5ms(not sure exactly what number this is?) of that was OTA time. So between deviation and betaflight there was 1ms-1.5ms. I did some betaflight measuring with a scope awhile back and I got .6ms best case (something like 1.2ms worst case - attached blue line in the scope). So deviation latency is roughly around .4ms-.9ms best case.

So to back calculate for redpine, the best case is 1.8ms. With similar deviation and betaflight latency, the OTA time is .3ms-.8ms.


I was using the motor outputs because I had the test set up for end to end latency and already have the python test script for that (and didn't have to dig into the code to add test code). I was testing other non spi receivers as well (crossfire and x4r so far) so that gave a pretty good apples to apples comparison.

planger, MPM = multiprotocol module right?

For my tests I was using a opentx nightly as of a couple months ago. For the tests linked (16-35ms) I just used the internal module and didn't use a MPM. That was to a spi RX as well, so the results actually are worse with a x4r using sbus (24ms to 40ms!).

**And oddly, reflashing x4r/xsr and using fport is 5ms better (19-35ms) apparently due to the better implementation of fport even though they are the same speed.

Ersky9x reflashed on the same taranis has a much lower latency of 14-23ms (x4r/fport). So for my taranis I switched to ersky9x!

Link to results:
docs.google.com/spreadsheets/d/1aTRuUzEI.../edit#gid=2048251012

There was a improvement in opentx within that last month but I haven't tested it and I don't think it was merged yet, I gotta check that out again.

For MPM, I did a couple manual tests before I had the nicer test setup (not as many data points). So there might be improvements since then. The MPM was worse then the internal module at that time, although that has been several months ago now. One comparsion was Frsky_D to a spi receiver on a FC was 27-48ms on MPM vs 24ms-35ms Internal Module.

Check under old manual test in the link above:

This is awesome work! Thank you!
Any chance this could be ported to A7105 chip (originally used in flysky). The chip allows for faster data rate than cc2500 - up to 500Kbps, so you would be able to reach 1kHz easily, maybe more.

files.banggood.com/A7105%20Datasheet%20v1.4.pdf

Edit: went through the code and looks like it's modified frsky_x protocol.
Couple remarks:
1. I don't think there is a need to have eu and lbt versions?
2. Is pxx scaling and converting back at the rx side really needed?
3. Please leave an option for 8 channel. I personally use 2 maybe 4 switches at most. I noticed last 8 channels are in one byte, so this would be easy to implement.

I like the idea of fixed data rate more than variable, but an option to switch the data rate in the tx is really awesome. The problem with variable data rate like in crossfire is that you don't really have control over when it is switching to lower data rate and the increased latency may catch you off guard when racing for example.

Great Job!
Are switches now also digital states instead of full channels?

Only thing using higher speeds should reduce robustness and range, but would be interesting to find out the relation between.

Maybe it could be made switchable? Like crossfire seems doing ?

Furthermore the future for me would be we send like defined status commands and have id’s on the sticks.
So in Betaflight no need anymore tondefins sticks en switches.
You just define ARM switch at tx, when rx send arm to flight comtroller should work.

Phobos,
Yes this was based off of frsky_x although the only part that is still the same is the bind packet. The A7105 looks like it could run basically the same packet and hopping scheme fairly easily. But at this point the proof of concept will be on the cc2500 because that is what I have.

The cc2500 can do 500kbps as well but I haven't tried that yet. I should be able to get to 1kHz at 250kbps with the current packet size, but either the packet building is taking too long or the channel hopping is adding to much to the time.
There isn't a EU, FCC anymore, but I was leaving room for a fast and slow. Slow at a much lower data rate. To change dynamically between the two I'd need to get telemetry running first, so the RX could tell exactly when to switch.

The pxx scaling is just so you can pack maximum resolution into to packet for the 4 analog channels. Otherwise you'd be giving up a couple bits of data to send data that is never used such as the values between 0 and 800.

I'm going to leave it fixed to 16 channels right now because the aux channels are only a 0 or 1. They aren't full analog channels. A 3 way switch would need two channels send the switch positions. So 4 3 way switches need 8 channels. Having that adjustable it would make it much more complex really wouldn't save much. 8ch vs 16ch on frsky_x saves a whole packet, 8ch here saves just a byte. Also this is just a proof of concept right now.

Fernandez,
Yes the aux channels are just digital states.

It will reduce range to run at the higher rate, but I'm looking at a slow mode for increased range as well.

For sending status commands that would take up a lot more room in the packet right and would as lot more work on both the betaflight and deviationTX side. Maybe with telemetry working you could run a slow link to do something like the lua scripts in opentx.