search

EdgeTX / edgetx

EdgeTX is the cutting edge open source firmware for your R/C radio
https://edgetx.org
GNU General Public License v2.0
1.5k stars 318 forks source link

NV14 - RX ID is missing #2340

Open pfeerick opened 1 year ago

pfeerick commented 1 year ago

Is there an existing issue for this problem?

What part of EdgeTX is the focus of this bug?

Transmitter firmware

Current Behavior

I just noticed that the NV14 does not show the Receiver ID field, although AFHDS 2A does support it (and is implemented by the MPM). It seems like the Flysky pulses driver does have at least partial support for it => STATE_SET_RECEIVER_ID, but although the comments around CMD_SET_RECEIVER_ID suggest maybe something isn't completely right still.

Expected Behavior

That the field be shown, and receiver ID be usable.

Steps To Reproduce

On the NV14, enable the internal FLYSKY module and note that the "Receiver" ID field is missing.

Version

2.7.1

Transmitter

FlySky NV14

Anything else?

It is not unique to this version - it seems to have been the case since the initial implementation, and hasn't been caught/resolved yet.

eshifri commented 1 year ago

Receiver ID is not present in any FlySky TX. I guess this was the reason to omit it in the original NV14 OTX implementation.

pfeerick commented 1 year ago

Do you know if with a non-OTX Flysky transmitter if receiver binding is model specific? I. E. If you change models the receiver wont work? As that would be the same as spektrum, where the rxid is implicit, rather than explicit. However, that then means you can't do things like cloning the tx (like you can with frsky, not sure if you can clone Flysky).

eshifri commented 1 year ago

Yes, for native FlySky AFHDS2A TXs binding is model specific.

raphaelcoeffic commented 1 year ago

As far as I know, both receiver and transmitter need to save some parameters from each other to communicate (see MPM code). In this context, I'm wondering how that can work without RX ID (designating the slot to be used in Tx module?).

eshifri commented 1 year ago

I'm sure that receiver ID mechanism can be implemented (since it works for MPM). I think FlySky is using model as a proxy:

  1. You cannot bind receiver to two TXs;
  2. If you copy a model both original and copied model will connect to TX. If you rebind the receiver, the second model will not connect.
raphaelcoeffic commented 1 year ago

@eshifri that is with a FlySky FW, right? Not with OpenTx?

eshifri commented 1 year ago

This is with all FlySky TXs I have seen and with NV14 OTX.

ajjjjjjjj commented 1 year ago

I have implemented receiver ID functionality for AFHDS2A in OpenTX for FlySky i6X: https://github.com/OpenI6X/opentx/pull/293/commits/2847594d36103fb6d1b9c6f7a2c43b82739a8ec3

It is mimicking Multiprotocol module behaviour by storing bound receiverId in general settings in 2D array while limiting max Receiver ids to 16, to do not increase settings size too much (AFHDS2A id is 4 bytes).

It works as expected from my tests.