Increase of receiver numbers from actual (00 to 63) up to a minimum (00 to 99) and desirable (000 to 256)

[Luznatural]

Is there an existing issue for this feature request?

• I have searched the existing issues

Is your feature request related to a problem?

When binding receivers with your radio, you can assign receiver numbers ranking from 00 to 63.
With the proliferation of electric planes and drones, it is very easy to have big numbers of planes/drones/helis in a single radio. Moreover, if you use big scale planes or big sailplanes, you could regularly use two or more redundant or connected receivers to move large quantities of servos. In my case, I have already used 53 numbers in my TX16 radio, so I am almost reaching the maximum number of receiver numbers options.

Describe the solution you'd like

Edgetx could try rising the receiver numbers available to assign to receivers.

Describe alternatives you've considered

1.- Increase the possibilities to assing receiver number from 00 to 99 instead of the actual possibilities (from 00 to 63). In this way you continue using the same 2 digits actual terminology, but offering adittional 30% possibilities, and hopefully there will be no need to code too much.
2.- Increase the possibilities to assign receiver numbers from 000 to 256. More coding and memory needed?

Additional context

No response

[3djc]

Most RF protocols don't allow that much, what do you use ?

FrSky and CRSF (Crossfire/ELRS) only allow 64 (0-63)

[Luznatural]

I normally use Frsky ACCST D16 protocol, and this is why I am asking the issue. But... why not asking Frsky and/or other providers to increase the numbers? Should not be very difficult.. I hope!!!.

[3djc]

On the contrary, likely quite difficult as those protocols are very rigid. Please do not hesitate to ask them, if they change, we will obviously adapt.

[pfeerick]

Also consider if it is strictly necessary to have unique receiver numbers for all craft... I.e. you could overlap craft with same primary controls, or of completely different type (ie. Heli vs plane). I highly doubt any manufacturer will change their already established OTA protocol increase the receiver id (where supported), but anything is possible.

…

On Sat, 10 Aug 2024, 8:51 pm 3djc, ***@***.***> wrote: On the contrary, likely very difficult. Please do not hesitate to ask them, if they change, we will obviously adapt. — Reply to this email directly, view it on GitHub <#5413 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ66KKMKPIMUINBJHXX4MLZQXWE3AVCNFSM6AAAAABMJW4HF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBQHE4DMNRQGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Luznatural]

Since I posted this issue, I have received a lot of posts and private messages supporting the initiative. The fact is many people is having the same or similar problem.
I build highly detailed large scale models, that takes years to build, so I use at least two receivers per plane, both for redundancy and for managing in PPM more than 8 servos. Actually, having the same receiver number in two different planes might present some conflicts, as the programming for different frames is diverse.
I think FrSky and other providers should consider to modify the protocols to support more receiver numbers to solve the problem. In the past, protocols didn't use receiver numbers. If the protocols do not allow that, perhaps Edgetx developers could find a way to do it outside the protocol (perhaps a Lua script that uses a modificador for the receiver number...) I do not know the correct way, but it's a real need.
I kindly request to consider it

[pfeerick]

Actually, having the same receiver number in two different planes might present some conflicts, as the programming for different frames is diverse.

It might. Which is why I said to try to re-use with different frame types... since a heli is not a plane... that might be your first clue that you have selected the wrong model. However, I know that is not a solution in itself. Nor is trying to use the same receiver number on models with the same primary control configuration. But this also then leads to ...

In the past, protocols didn't use receiver numbers.

... at which point I need to ask what are you actually trying to say there? That this was a good thing, in which case, what does limited numbers of receiver numbers matter, since you can set it to zero and forget about them entirely? Or that this was a step forward (to which I only partially agree - as it has also resulted in complacency, and failure to do surface checks before flight - since there is no need to "double check" you have the right model selected).

If the protocols do not allow that, perhaps Edgetx developers could find a way ...

I'll stop you right there... if the protocol does not allow for that, it does not allow for that. There is nothing we can do to extend or workaround, zilch, nada. To even attempt that is asking for someone to get hurt.

If you have enough people asking for this, you're best and really only option is to contact the manufacturers to request they add support for more receiver numbers. Once this is supported a RF protocol, then we can support it also.

[Luznatural]

Peter,
Thanks for your response.
I have been reading carefully through my previous post and didn't try to be rude or disrespectful in any part of it. My apologies if that's what resulted.
I am a constant supporter of Edgetx since the very beginning of your proyect, even making a personal yearly donation, as I firmly believe you are doing a great and important job on the benefit of all the RC community, and you have developed wonders for enhancing and easing the way pilots interact with their radios and airplanes, and also delivering nice good new capabilities.
SInce the appearance of OpenTX and then EdgeTX, I understood that this marvelous hobby, vocation and profession has been transformed into a more collaborative effort: Users and developers request enhancements and provide clues and help, and the developers very frequently respond modifying their products, firmwares, and software. I hope this will continue being so. But this is a paralel efort. I have no doubt that if both users and developers request enhancements at the same time, the providers will pay far more attention. I sincerely believe that if EdgeTX developers request something to the providers, they will listen for sure.
If I have offended you in any way, I do sincerely apologize.
Warm regards

[3djc]

Well, let's be honest, FrSky doesn't support EdgeTX in any way, shape or form, and if anything, would be delighted to see us gone for good. So us asking to FrSky surely won't help !!!!

And if they do listen to users requesting it, it will likely be changed only for access/tandem receivers anyway.

Not saying that just to be negative, it simply is that way

[pfeerick]

If I have offended you in any way, I do sincerely apologize.

No offense was taken, and I am sorry if my reply made you think otherwise. I was simple calling this issue what it is... basically unsolvable by us. As JC said, with FrSky as an example of the manufacturer of both handset AND RF system that OTX has history with, little to nothing will come of us contacting them - the power is with you guys as their customers. And to be honest, we don't have any sway with any of the RF manufacturers... only the handset manufacturers (which is completely difference, as the MPM is the go-between there). If we did, we would certainly try to help get the message across.

The only protocol I would think could change any time soon, given enough demand from their user base, would be ELRS - which is also limited to 0-63 slots - and that may only be possible across a major version change, as it would probably break the existing OTA protocol.

[pagrey]

I think the RX number can be the same if you are using a Multiprotocol module and different protocols. For example you can have 60 FrSky receivers and 60 Flysky. The ID is stored at a different address on the chip. If anybody is interested the memory layout then it starts at line 823 of the Multiprotocol.h source file. I'm not sure if Pascal choose the numbers for all the protocols based on a tested maximum or just stuck with a maximum of 64.

Companion does seem to highlight duplicate entries in red even if the protocol is different but I don't think it's an issue.

If you do run out of FrSky receiver numbers and you are using a Multiprotocol module you could start using another brand like Flysky and you'd probably be fine.

[pfeerick]

Yes, the receiver ID is RF module/protocol specific... it is nothing specifically to do with EdgeTX/OpenTX... and the red highlight in Companion is only a warning that the receiver IDs are duplicated... Companion isn't smart enough to take into account the MPM/RF protocol in use 🙃

So you can could reuse receiver ID 1-60 across Frsky X/X2, Flysky AFHDS 2A, Spektrum DSM2/DSMX, etc, to get 180 models (assuming all three protocols support 60 unique receiver IDs).