msp performance on tw range of receivers.

[robthomson]

I have recently built a small tool to anaylise msp throughput to the rotorflight flight controller.

This tool is relatively simple.

For 30s it requests large msp datasets from the fbl; and then returns some stats around what the outcome was.

Stats in my case are as follows:

ELRS: Total queries: 50 Succesfull queries: 50 Timed out queries: 0 Protocol retries: 4 Average query time: 0.6s

FRSKY ARCHER: Total queries: 49 Succesfull queries: 49 Timed out queries: 0 Protocol retries: 4 Average query time: 0.61s

FRSKY TW Total queries: 42 Succesfull queries: 42 Timed out queries: 0 Protocol retries: 14 Average query time: 0.71s

In all cases I am on a Tandem Pro - Ethos 1.5.15 and latest RF/RX firmwares.

Whats absolutely clear is that the TW protocol is lagging behind. It has taken considerable effort and sacrifices within RF2ETHOS to make the TWRX receivers work due to the high amount of retries. These stats clearly show the issue.

Functionally.. the TW receivers have fanstastic range and latency - but there is an issue that needs investigating on the delays / retransmits when sending sport data.

It would be great if this could be looked into.

Rob

[mawzthefinn]

That's interesting, especially since another user actually found that FBus sensor throughput on TW with the RB35S appeared higher than for TD/ACCESS (ie less sensor frames dropped for the same large number of sensors)

[rburrow87]

I believe Rob is using LBT, right?

Here are my findings after digging into the receiver bag:

X20RS FCC Ethos 1.5.15 TD-ISRM Pro 1.1.14

ELRS 3.4.3 (D500 1:4) Total queries: 53 Successful queries: 53 Timed out queries: 0 Protocol retries: 1 Average query time: 0.57s

TW R6 1.0.6 Total queries: 52 Successful queries: 52 Timed out queries: 0 Protocol retries: 2 Average query time: 0.58s

TW MX 1.0.6 Total queries: 47 Successful queries: 47 Timed out queries: 0 Protocol retries: 7 Average query time: 0.64s

TW Mini 1.0.7 Total queries: 26 Successful queries: 26 Timed out queries: 0 Protocol retries: 49 Average query time: 1.15s

TD MX 1.0.13 (HW 1.5.0) Total queries: 51 Successful queries: 51 Timed out queries: 0 Protocol retries: 2 Average query time: 0.59s

Archer Plus RS 1.0.9 Total queries: 52 Successful queries: 52 Timed out queries: 0 Protocol retries: 1 Average query time: 0.58s

Archer RS 2.1.10 Total queries: 51 Successful queries: 51 Timed out queries: 0 Protocol retries: 2 Average query time: 0.59s

R-XSR ACCESS 2.1.8 Total queries: 51 Successful queries: 51 Timed out queries: 0 Protocol retries: 1 Average query time: 0.59s

R9MX 1.3.1 Total queries: 21 Successful queries: 21 Timed out queries: 0 Protocol retries: 84 Average query time: 1.43s

Not sure what is up with the TW Mini. Unfortunately I don't have a second one to see if it's a hardware issue. I re-ran this one and power cycled everything several times to be sure.

The Archer Plus RS seemed to require a power cycle after binding or it would produce a lot of errors, which sounds like a familiar quirk from doing some ACCESS vs ACCST F.Port debugging with Rotorflight last year.

The R9MX was so bad that it was difficult to load RF2Ethos due to all the errors (since it checks MSP version upon opening). I re-ran this one and power cycled everything several times to be sure. Edit: I just ran across this, will re-run the R9 test later with it and see if it makes a difference https://github.com/FrSkyRC/RF_Feedback_Group/issues/43

[robthomson]

Certainly seems like the mx series have something odd going on

[Jiki-Mo]

X14 FCC Ethos 1.5.15

ELRS 3.4.2 (500 1:4) Total queries: 50 Successful queries: 50 Timeouts: 0 Retries: 0 Checksum errors: 0 Average query time: 0.56s

[robthomson]

So intitial tests on the beta firmware on TW receivers and X20PRO

old firmwere:
0.6s avg query time retries 10

beta firmware 0.53 avg query time retries 2

This initially seems positive.

[robthomson]

So all up there is still something functionally wrong with the TWMX msp implimentation.

Typical example:

• connect. send msp. Its supper fast.
• wait 2 mins
• do same test. all initial speed lost and very slow.

[rburrow87]

Yes I've noticed the same issue with Twin in both v3 beta and the current release versions. Every now and then it'll connect and perform flawlessly, but more often than not, it ends up slower and with many more errors/retries in this test.