edgetx icon indicating copy to clipboard operation
edgetx copied to clipboard

NV14 - RX ID is missing

Open pfeerick opened this issue 3 years ago • 3 comments

Is there an existing issue for this problem?

  • [X] I have searched the existing issues

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.

pfeerick avatar Sep 21 '22 09:09 pfeerick

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

eshifri avatar Sep 21 '22 16:09 eshifri

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).

pfeerick avatar Sep 21 '22 23:09 pfeerick

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

eshifri avatar Sep 21 '22 23:09 eshifri

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?).

raphaelcoeffic avatar Sep 25 '22 18:09 raphaelcoeffic

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.

eshifri avatar Sep 25 '22 18:09 eshifri

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

raphaelcoeffic avatar Sep 25 '22 19:09 raphaelcoeffic

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

eshifri avatar Sep 25 '22 19:09 eshifri

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.

ajjjjjjjj avatar Nov 02 '22 10:11 ajjjjjjjj