EMUFLIGHT SPI RX on Xlite S can't bind

[KnzHz]

Hello

I'm using Emuflight on a meteor65(matek411rx) and it works perfectly on it with my Taranis.

However, it can't bind on Xlite S. I see the same issue on Betaflight, but not the latest versions, seems this fixed it:

https://github.com/betaflight/betaflight/pull/9218

or this:

https://github.com/betaflight/betaflight/pull/9418

based on this issue/topic:

https://github.com/betaflight/betaflight/issues/8603#issuecomment-578990424

When using latest stable version of beta flight I can bind.

There's no LBT/FCC version of Xlite S firmwarewise it seems but I've tried every firmware version available.

I've just tried 0.2.50, same issue.

in BF there's an option called FRSKY_X_LBT that I use, I don't know if that's the difference but as I said, Emu works perfect with Taranis QX7 and XD9, I'm only having issues with Xlite S.

[Kaiowarez]

According to one of the testers gotta use cli command for binding for it to bind, again according to tester let me know if it works for you

[KnzHz]

Hi

I've already tried that (in emuflight it's just "bind", in BF it's bind_rx) but I retried just to make sure.

[gretel]

use FCC firmware. any recent opentx will do. this wontfix in emuflight.

[KnzHz]

Like I wrote, the fcc\lbt trick is dead on the new controllers as the new modules don't have two firmware versions anymore.

[gretel]

like i wrote, it does work, cause i do fly it.

[KnzHz]

Then you're made of unicorn magic. I'm pretty sure just flashing opentx as fcc won't change anything other than adding d8 option. Is that what you did? Or do you happen to have a xlite s already fcc? Nobody on the betaflight github could get it to work before the fix either so I'm curious as to how you set it up in both emuflight and opentx? The lite s doesn't use the xjt module anymore but a new one, did you pick a specific firmware on the xlite s then? I feel like I tried everything. I'll stop powering now as clearly the attitude towards issues is stfu.

[gretel]

the attitude is like it will not fix in emuflight, because nobody is contributing any changes for now, including you. thanks.

[nerdCopter]

We are an extremely small dev group and are slow to look at all the issues. This issue should remain open until definitively reviewed/confirmed/fixed. Unsure if anyone in our testing group has an xLite "S" to assist testing at the moment. @KnzHz thank you for the links, such will be helpful.

[nerdCopter]

@KnzHz Can you confirm the following: FIRMWARE-ISRM: # 7. To be compatible with v2.1.x ACCST firmware for ACCST D16 mode.Note: Please update the firmware of all your radios(latest openTx or FrOS), RF modules and receivers accordingly. i.e. 1) your OpenTX is latest (v2.3.7 direct from open-tx.org) 2) ISRM firmware v2.1.0 3) unsure about d8 vs d16, maybe try both.

[KnzHz]

Hi

I fly crossfire myself so I was helping a friend, I don't have the xlite S at hand right now but I did try the latest version of OpenTX, I even stooped so low as to try frskys own build :-P i tried with both ISRM firmwares and in both d8 and d16 mode. I tried binding with the button and through cli(in BF I've had the best luck with cli). I tried a regular Xlite and got that working on fcc with d8 though.

Next time I can get my hands on his transmitter I'll try again with the different versions but I spend like three hours just trying every possible option. I got him flying with BF but Emu just makes whoops sooo much better, it's insane! Kudos to all of you devs, this is like new energy into the hobby!

[nerdCopter]

Thank you for the troubleshooting. I was told that if it is bound on BeF, then it would remain bound for Emu. I'll leave open, if you solve, please let us know. if issue goes stale, at some point it will be closed again.

[cynfewl]

@KnzHz I have my EmuFlight PMB tuned whoop bound to an X-Lite Pro running OpenTX 2.3.7 (though it also worked on OpenTX 2.3.3), but I have not upgraded it to the 2.1.0 firmware as I'm not sure how well this is supported in BetaFlight or EmuFlight at the moment. From what I read it's pretty experimental and based on the multiprotocol module implementation, which uses different hardware to the ISRM board in the ACCESS radios.

At the moment I have it bound in D16 mode and I have tried to use telemetry, but although control is fine, telemetry is not working for me (drops out after a couple of metres). I assume this is because EmuFlight is based on Butterflight 3.5.7 and the only reliable D16 with telemetry release for ISRM radios and SPI receivers is BetaFlight 4.1.1. I think even BetaFlight 4.2 doesn't work reliably with telemetry and people are reporting reduced range vs D8.

All of this has lead me to get a lite multiprotocol module and I am in the process of using this for all my SPI receiver based quads and ACCESS series radios as D8 just seems to be better in this situation and the only thing I am really losing is failsafe settings from the radio. My theory is this isn't really as important on whoops compared to bigger quads since the batteries and props are smaller.

I also have vague plans of comparing the SPI receiver code between EmuFlight and BetaFlight 4.1.1 and trying to get at least the v1 D16 mode working with telemetry, but my coding skills are ordinary and it wouldn't help with 2.1.0 firmware anyway.

[KnzHz]

@cynfewl Nice, I'll see if I can try that, this COVID-19 thing is making me seeing my friend with there transmitter less common and he doesn't have the technical skills to do it himself.

Is yours LBT or FCC?

[cynfewl]

@KnzHz I am running FCC firmware.

[cynfewl]

I finally got around to some more testing and found the following:

Updating to opentx 2.3.9 doesn't make any difference. D8 with a IRX4 lite multiprotocol module running the latest code works fine with or without telemetry enabled. D16 FCC using the ISRM board in an x-lite pro works but results in "telemetry lost/telemetry recovered" warnings pretty much constantly, even if you bind the radio with telemetry disabled.

This last one is confusing, because I would expect it wouldn't alert if you have bound without telemetry, but apparently the SPI receiver sends RSSI regardless of the telemetry option you choose at bind. If I disable alarms under RSSI in telemetry it no longer warns and vibrates every couple of seconds, but opentx then gives me a warning at startup, which I don't seem to able to disable.

I have also checked with betaflight 4.2 and I do not see the same issues, so it seems like the betaflight code is now stable with respect to SPI receivers. Comparing the code there are quite a few differences, some of which refer to telemetry, so chances are integrating this code would fix the problem. Alas some names have changed and it seems like modifications would need to be made to a number of files, most likely putting this beyond my limited coding.

[nerdCopter]

very good info. as you said, yes there are many file changes. if it were simple, it could make it into 0.3.x, but i think these things will have to be part of the next major release which is already in the works, albeit will not release any time soon.

if we get past some of our current tasks, maybe this will be looked into. we appreciate your troubleshooting and efforts!