Initial FrSky ACCST V2.1.x support

[MJ666]

Tested on bench with a Devo10 and an R-XSR receiver (V2.1.0 FCC firmware). The RX will bind as usual and telemetry is received and looks reasonable. The channel data are checked with the BetaFlight configurator with the RX connected to an AlienFlightNG Anubis16 flight controller. V1.x.x FCC mode is also still working as expected. The LBT (EU) mode is not yet tested. More testing and feedback is welcome. The code came partially from the MPM:

https://github.com/pascallanger/DIY-Multiprotocol-TX-Module

Edit: I really don't wanted to offend anyone here. Fur sure this work would not be possible without Pascal's efforts to reverse engineering the protocol. Many thanks go to him for the initial implementation. Since I was looking for deviation support of the V2.1.x protocol I used the opportunity and based my code on his work. I also posted in the Deviation forum to ask if anyone is already working on this before I looked into the code:

https://www.deviationtx.com/forum/protocol-development/8682-frsky-accst-v2-1-x-protocol-support

Locks to be my initial thinking to reference the source of the code was not good enough and I want to apologize for this.

[pascallanger]

When you say "partially", all the modifications you've applied come from my code... A thank you for the long hours I've spent reversing this protocol would be appreciated...

[MJ666]

For sure the updates I applied to deviation are completely based on your code. Parts are a plain copy and other parts are rewritten and modified. I definitely appreciate the work you have done for MPM and whitout this my work would not be possible.

[TheRealMoeder]

I'm sure MJ666 didn't try to offend you Pascal. @MJ666 Why not just add a small comment in the code referencing Pascal's MPM work in this protocol? You can find such reference in other protocol modules as well. Nonetheless: Thanks to both of you for the hard work!

[pascallanger]

That's not what I meant... I was just saying you can add a thanks note when porting a protocol to the author in the pull request. That's all...

[MJ666]

Also bench tested LBT firmware with R-XSR LBT V2.1.0 firmware. Chanel output looks to be OK but telemetry RSSI (around 120 when RX and TX near by) and LQI (static 127 not depending on distance) values looks to be strange on LBT. For the FCC firmware values lock to be OK. RSSI is around 100 and LQI around 50 when RX and TX are near by.

[TheRealMoeder]

I have no RX to check this. I'd prefer a some more positive feedback before merging if possible.

[MJ666]

Have tested this some more with theR-XSR all firmware variants and a updated version of Betaflight: https://github.com/betaflight/betaflight/pull/9697 I successfully flight tested this with all four protocol variants. I have see some telemetry issues with BF wich is likely still in the Betaflight code. It looks to be LBT v 2.1 is mostly affected. I now also have an Jumper T16 with the MPM. The telemetry values i can see with the R-XSR are very similar to what i can see with the updaded Deviation code. Some values are quite different between the firmware variants for some reason. With LBT I have very high LQI values. If there is someone out there who requires a binary for testing please let me know your TX and I can build them.

[pascallanger]

I had to adjust the protocol timing for the telemetry (while developing before the release, nothing has changed since the release and I have no complains). Rssi/lqi is usually something but the number of packets per seconds is the true indication. For example all the telemetry looked to work but I was only receiving a third of the packets... I haven't checked your code but I also implemented LBT per the local regulation (not the protocol name but really listen before talk). Pascal

[MJ666]

I made some comparison between DEVO10, Jumper T16 (MPM) and the four protocols. (MPM). Here are the test results:

`DEVO v1 FCC RSSI 89-92 LQI 43-47 LRSSI -11- -17 VOLT1 3.3V

DEVO v1 LBT RSSI 94-96 LQI 127 statisch LRSSI -16- -23 VOLT1 3.3V

DEVO v2.1 FCC RSSI 115-116 LQI 41-46 LRSSI -21- -26 VOLT1 3.3V

DEVO v2.1 LBT (looks to be only sporadic updates) RSSI 109-112 LQI 127 statisch LRSSI -16- -23 VOLT1 3.3V

T16 v1 FCC TRSS 120-121 TQIy 42-48 RSSI 100-101 RxbT 3.5V

T16 v1 LBT TRSS 97-100 TQIy 127 statisch RSSI 96-99 RxbT 3.5V

T16 v2.1 FCC TRSS 105-110 TQIy 40-46 RSSI 103-106 RxbT 3.5V

T16 v2.1 LBT TRSS 105-110 TQIy 127 statisch RSSI 103-106 RxbT 3.5V ` The R-XSR is here only powered by 3.3V when connected to the FC on the bench. I also did some tests with a 5V supply but this has not affected the results. The results with the BETAFPV F4 FC 1S Brushless FC look similar. There are some difference how MPM and deviation is showing the telemetry data. I can see for V2 LBT the telemetry is very unstable with the Devo but not with the MPM. I did quite some flying with the BetaFPV last days with all different protocols including the V2 LBT and have not seen any issues at this side.

[pascallanger]

Again, you are looking at RSSI, TRSS TQly which are not good indicators. You need to look at the packets per seconds on the telemetry to have a real idea of what's going on.

[vladislavy]

arm-none-eabi-ld: objs/devo7e/frskyx_cc2500.elf section .text' will not fit in regionram' arm-none-eabi-ld: region `ram' overflowed by 454 bytes make[1]: [objs/devo7e/frskyx_cc2500.bin] Error 1 make[1]: Waiting for unfinished jobs.... make: *** [zip_devo7e] Error 2

devo7e protocol module can't fit to 4K

[MJ666]

Not sure what options we have to shrink the size of the module. Likely we need to Keep the devo7e without v2 support and add a compile time option for this?

[vladislavy]

You can use MODULAR for it.

[TheRealMoeder]

init_hop_FRSkyX2 looks pretty expensive with all its comparisons. Any ideas to shrink this? Other Option would be to put FRSky V2 in separate module

[MJ666]

@vladislavy updated the PR according to your advice.

@TheRealMoeder this code allows the bind information to be build in the proven way. Since this algorytm results in a table depending on the variable ID on TX and RX side. Not sure how this can be simplified without breaking something. A separate module would be possible but will impact the usability for all Deviation users and is duplication a lot of code. The image size for all transmitter will grow even more.

[TheRealMoeder]

There should be more room for optimization on the code, I can also see some pattern in the exceptions. I'll try to have a look into it

[TheRealMoeder]

Looking at @pascallanger 's MPM code, he generates most part of the CRC table. Reusing the same code we can save 464 bytes in my quick test. Didn't check functionality, just copied the function, but I don't see why it shouldn't.

edit: additionally a few bytes can be spared by adding a for loop for the exceptions, but < 10 bytes to gain - mileage may vary depending on compiler version ;)

[MJ666]

Replaced CRC calculation code and it fits to the Devo7e module now. Thanks to @TheRealMoeder for the heads up and @pascallanger for the smaller code size.

[pascallanger]

@goebish The Multi FrSKy_RX can already auto bind D8, D16 v1 (FCC/LBT) and D16v2.1 (FCC/LBT). I've also added a CloneTX mode which enables someone to duplicate the ID&Hop of a TX sending FrSky for all 3 modes. Pascal

[MJ666]

I rebased now and tested the updated CRC code with a single protocol. All protocol variants are fligth tested before this change a few times with the BetaFPV FC. I also have bench tested all protocols with a original FrSky R-XSR receiver connect to an AlienFlightNG FC and the BF configurator.

[vladislavy]

You need correct HOP_DATA_SIZE or HOPP_DATA_SIZE.

[MJ666]

You need correct HOP_DATA_SIZE or HOPP_DATA_SIZE.

Sorry my bad. Fixed.

[vladislavy]

Now devof7 protocol module doesn't fit, overflowed by 6 bytes.

Try to use 32 bit counters (inside any for()), it will provide more compact binary: for (u32 i = 0; i < HOPP_DATA_SIZE - 1; i++)

[MJ666]

Mhhh, to big now for DevoF7. Changing the type even in multiple of the for loops and also to remove the bind options for the modules will not make any change on this 6 byte overflow. Need to find other options.

[TheRealMoeder]

This loop saves enough space. Please double check channel calculation!

static void init_hop_FRSkyX2(void) {...} for (u8 i = 0; i < HOP_DATA_SIZE; i++) { channel = 5 ((u16)(inc i) % 47) + offset; // Exception list from dumps for (u8 k = 0; k < 2; k++) { if (Model.proto_opts[PROTO_OPTS_FORMAT]) // LBT or FCC { // LBT if (channel <= 1 || channel == 43+k || channel == 87+k || channel == 129+k || channel == 173 +k) channel += 2; else if (channel == 216+k || channel == 218) channel += 3; } else // FCC if (channel == 3+k || channel == 46+k || channel == 90+k || channel == 133+k || channel == 176+k || channel == 220+k) channel += 2; } hop_data_v2[i] = channel; // Store } hop_data_v2[HOP_DATA_SIZE] = 0; // Bind freq }

[MJ666]

This is what im actually working on. I don't realy understand why the complex code need less space but anyhow.... It fits but I need to retest the V2 protocols. :-) Stay tuned.

[MJ666]

After cleanup and some more fixing it finaly fits all targets with full functionality. I have done again some testing with R-XSR, XM+ and the BetaFPV FC. With the BetaFPV whoop i did sucessful flight tests with all four protocols. There is still a bind problem with LBTv1 and the BF test code (https://github.com/betaflight/betaflight/pull/9697) im using but this is also there with the Jumper t16 (MPM). Dont have an orginal FrSky TX for testing. Since hopping tables are identical with FCCv1 you can fly without issues. Binding is working for all Protocols with original FrSky receivers. Bench tests with them dont show any problems. Unfortunately all my FrSky receivers are soldered into my small quadcopters and are not easily can be updated.

[TheRealMoeder]

@MJ666 Could you also update deviation-manual with the new protocol options?