FrSky ARCHER PLUS R10+ and SR10+ receiver support

[kochpet]

Is there an existing issue for this feature request?

• [X] I have searched the existing issues

Is your feature request related to a problem?

The Frsky R10+ receivers have 10 configurable channel ports, each channel port can be assigned as PWM, SBUS, FBUS, or S.Port. At the moment you can only change the channel mapping for the 10 ports.

Describe the solution you'd like

The possibility to configure all channel ports also to PWM, SBUS, FBUS, or S.Port.

Describe alternatives you've considered

No response

Additional context

No response

[raphaelcoeffic]

To be able to implement this, we will need some information on how is this done. At the very least we need a trace of the packets exchanged during this configuration between radio and module.

Last time I asked if anyone would be ready to do this kind of things and maintain the FrSky protocols, nobody showed up.

This probably means we won’t be able to support this hardware, as we’re not receiving any information from the vendor.

[kochpet]

Hi Raphael, thanks for your reply. At the moment you can only configure the ports of the Archer Plus series with ETHOS to PWM, SBUS, FBUS, or S.Port, for this I flashed one of my transmitters to ETHOS.

The reconfiguration of the ports as well as changing the chanel mappings happens with a bound RX under options. I would like to support you in the implementation if you tell me how I can help you! Attached two screenshots from Ethos.

[raphaelcoeffic]

@kochpet what we need are the data exchanged between the radio software and the RF module. This means using a logic analyser with probes on the serial lines between the RF module and the main MCU in your radio.

Other vendors just document their communication protocol so that we "just" have to implement it. This requires to reverse-engineer the protocol itself, whereby we already have a good part of it (from the time FrSky was communicating some details to the OpenTx team), but we need the new parts now.

[kochpet]

@raphaelcoeffic Ok, just to clarify my background. I'm an IT consultant and I work for a company that develops and builds electronic devices. It should be possible that I can provide you with this data. Can you tell me where exactly I have to attach the logical analyzer. I would use a Frsky X10S ETHOS with an internal ISRM module for this.

[raphaelcoeffic]

@rotorman can you please help this gentlemen with the pinout of the internal module connector? It is the same as on the TX16S.

[raphaelcoeffic]

Once the packages have been monitored, the single packet payload need to be exported and analysed. I usually write python scripts to do that. Otherwise it's quite hard to find the exact packet or sequence of packets you are looking for.

[rotorman]

Here a pinout of the TX16S 12-pin RF module connector:

@kochpet Would you happen to have a Saleae logic analyzer? Tapping the internal module RX and TX pins would reveal it's secrets. Alternatively you could use two 3.3V logic level FTDI adapters, one for TX and one for RX line, but logic analyzer is better, as it shows combined timing of the RX and TX lines better.

[raphaelcoeffic]

You are looking for a "normal" async serial (8N1) with a baud rate of 450.000.

This is the code for the current receiver settings as we know it: https://github.com/EdgeTX/edgetx/blob/5f171560360ab3982724c2ecc6fba3fc6fe30e16/radio/src/pulses/pxx2.cpp#L397-L419

[kochpet]

@rotorman on the X10S IXJT motherboard is a 13pin Molex and not a 12pin like at your photo. Do you have a pinout for that too?

[kochpet]

@rotorman Don't worry already found it

[kochpet]

@raphaelcoeffic Ok, I'll get the Logical Analyzer on Monday, then we'll see. In the meantime, a possibly stupid question. As I can see at the code you know how to switch the separate port for SBus, Fport......etc on existing receivers. Since the R10Plus registers and binds perfectly and the port mapping also works perfectly, the receiver can also be switched to 7ms PWM mode and telemetry can be disabled, it would not be possible for the reconfiguration of the ports to work with the existing code?

[raphaelcoeffic]

It‘s hard to guess, I don’t have the hardware, so I cannot test, and it feels weird to make blind changes. Let‘s see what traces show first.

[kochpet]

@raphaelcoeffic Can you please check the Saleae logic file, I think this is one of the sequences we are looking for.

Pin1toFBUS.zip

[kochpet]

@raphaelcoeffic did you find time to check the Saleae logic file?

[raphaelcoeffic]

@kochpet it seems your ZIP file has only the picture, right? Is there any way I can have the full Logic2 trace file? I need to see the traffic around it as well (request + replies, etc).

[kochpet]

@raphaelcoeffic Sorry, I zipped the wrong file, here are all the .sal of the various switching processes. Analyzer.zip

[raphaelcoeffic]

@kochpet did you actually have "Telemetry disabled" activated? It seems bit 7 is always set in your traces, which seems odd.

Also:

• can you choose the output pins freely? (every type of output on any pin?)
• can you have multiple SPORT pins? (same for SBUS in/out)

[kochpet]

@raphaelcoeffic Yes telemetry was disabled

[kochpet]

@raphaelcoeffic 10 Configurable Channel Ports CP1: PWM / SBUS Out / FBUS / S.Port / SBUS In CP2-10: PWM / SBUS Out / FBUS / S.Port

[raphaelcoeffic]

@kochpet it seems we're missing the capability frames in the trace. You should be able to see at some point (possibly when opening the receiver options?) a frame coming from the module starting with 0x7E [size] 0x01 0x06.

[kochpet]

@raphaelcoeffic let me check, I make a new trace

[kochpet]

@raphaelcoeffic this is the trace when i open the OPTIONS menu

Press_Options.zip

[raphaelcoeffic]

The receiver sends 0x70 as its capabilities, so basically bits 4, 5 and 6 are set (0111 0000). Bit 4 is supposed to be "Racing mode" (do you even see the option in the menu?), but we don't know what bits 5 and 6 mean.

enum ReceiverCapabilities {
  RECEIVER_CAPABILITY_FPORT,                          // bit 0
  RECEIVER_CAPABILITY_TELEMETRY_25MW,
  RECEIVER_CAPABILITY_ENABLE_PWM_CH5_CH6,
  RECEIVER_CAPABILITY_FPORT2,
  RECEIVER_CAPABILITY_RACING_MODE,                    // bit 4
  // missing bit 5
  // missing bit 6
  RECEIVER_CAPABILITY_COUNT
};

We would probably need to see what other receivers will reply, and see what the difference is in terms of supported features.

[kochpet]

This is the caprure for the High PWM Speed ​​mode High PWM Speed.zip

[kochpet]

@raphaelcoeffic Would it be possible that bit 5 and 6 is responsible for switching from SBUS-16 to SBUS-24, you have the trace for it SBUS16-24.sal

[raphaelcoeffic]

Capabilities and settings are 2 different things! It is not the same bitfield. But yes, the Receiver settings frame, bit 5 is definitely used to switch SBUS to 24CH channel mode. However, only one bit is required, and there is no relation between settings and capabilities, they don't use the same bits and the frames are different.

[raphaelcoeffic]

Fast PWM was already know and AFAIK already supported. These are the known settings bits (general, not per channel):

#define PXX2_RX_SETTINGS_FLAG1_TELEMETRY_DISABLED  (1 << 7)
#define PXX2_RX_SETTINGS_FLAG1_READONLY            (1 << 6)
#define PXX2 RX_SETTINGS_FLAG1_SBUS_24CH           (1 << 5) // new
#define PXX2_RX_SETTINGS_FLAG1_FASTPWM             (1 << 4)
#define PXX2_RX_SETTINGS_FLAG1_FPORT               (1 << 3)
#define PXX2_RX_SETTINGS_FLAG1_TELEMETRY_25MW      (1 << 2)
#define PXX2_RX_SETTINGS_FLAG1_ENABLE_PWM_CH5_CH6  (1 << 1)
#define PXX2_RX_SETTINGS_FLAG1_FPORT2              (1 << 0)

For the channel output, special values in the output mapping array are used. So far I noted from your traces:

        // (1 << 5) SBUS in  (0x20)
        // (1 << 6) S.PORT   (0x40)
        // (1 << 7) SBUS out (0x80)
        // SPORT | SBUS out  (0xC0)

Please note that values up to 23 are reserved for normal channel mapping.

Possibly, the capability bits are mapped to these 2 features. The question is: which is which? So we'd need to have a receiver that has only one of the afore mentioned capabilities, so we can determine which is which. Or we can try a blind guess based on the "historical" context (which feature appeared first), but development and shipping are 2 different things, the order could be reversed.

[kochpet]

Ok, how can we continue, try and error?

[raphaelcoeffic]

Looking at the tandem receivers, it seems SBUS 24CH is a newer feature, so I would assume this is missing bit 6, while the "Configurable Channel Ports" (PWM / SBUS Out / FBUS / S.Port) would be missing bit 5.

[kochpet]

Unfortunately, I can't test this with a tandem receiver because I only have an X10S Express transmitter. But we wouldn't need tandem receivers for EdgeTX anyway!

[raphaelcoeffic]

Also, we should note the following receiver IDs / names:

0x40    "SR10 Plus"
0x41    "R10 Plus"

[kochpet]

@raphaelcoeffic Do you think that you can compile a test version for a TX16S with the current level of knowledge?

[raphaelcoeffic]

Should be ok. I’ll have something in the next days.

[raphaelcoeffic]

@kochpet I'm still missing an answer to this question: can you have multiple SPORT pins? (same for SBUS in/out). Meaning: once you have configured for example "S.PORT" output for pin 1, can you select "S.PORT" output also for another pin? (same question for SBUS/FBUS). This is quite important for the UI.

[kochpet]

@raphaelcoeffic Yes, you can configure multiple ports, see screenshot. But only Pin1 can also be configured as SBUS In. Pin1: PWM / SBUS Out / FBUS / S.Port / SBUS In Pin2-10: PWM / SBUS Out / FBUS / S.Port

[raphaelcoeffic]

Ok, then it's the way I implemented it in #3249.

[kochpet]

@raphaelcoeffic Hi Raphael, can you compile a test version for my TX16S. Would like to test whether all the functions really work now.

[pfeerick]

To access the automatic builds for a PR, first open up the PR page. Under the PR title, you should see a series of tabs (Comments, Commits, Checks, Files Changed). Click on the Checks tab. Then if you are after the radio firmware, click on the link on the left side mentioning firmware. If you want a Companion/Simulator build, pick the one that suits your operating system. Then, under the 'Artifacts' heading will be a link to the zip file containing either the firmware or companion package.

i.e. the PR is mentioned above, as well as at the top of the page, as being #3249, and the latest build run for that is https://github.com/EdgeTX/edgetx/actions/runs/4251600010

However, I will probably need to trigger a new run as that build is about to expire.

It would be great if you can give it a try, and let us know what the status of this now, so that it has had some real-life testing ;)

[kochpet]

Hi, I have now tested the new functions for the Archer R10+ with the firmware tx16s-e50d024 and unfortunately have to report that switching the ports does not work at all. Also, the current port status is not displayed in the options screen. I tested with an Xact servo and a FLVS, as soon as the port is reconfigured it's like dead, it doesn't matter whether the port is configured as SPort, Sbus or Fport. If the port is reconfigured back to PWM, it will work normally again.

[kochpet]

@pfeerick Will further actions follow in this regard and do you need any information from me.

[pfeerick]

Raphael has been tied up with real life for the last two weeks so will probably follow up on this soon to chase up on what's needed if this is still something we can debug blind.

[raphaelcoeffic]

Given the difficulty of doing “remote debugging”, without any possibilities to do any local tests, I think I should order one of these to test myself… that would be another 60-70€ of our donations going to a vendor that does not support us…

[kochpet]

@raphaelcoeffic I have 2 pieces of the R10+ and at the moment the receivers are almost worthless for me as I certainly won't switch to Ethos. If you send me your address I can support you with one of the two R10+. The experience you make with it is certainly also an advantage for the new RB25 etc., as they have a similar principle of port switches.

[jogybaer0815]

It would be a great achievement if the Archer R10 with its bus system, especially the F.Bus, were supported by EdgeTX. If an Archer R10 is needed to achieve this goal, I would also be happy to donate a receiver. Greetings

[DaTwo]

Is this still being worked on? The R10+ RX sounds perfect for us gasser pilots.

[r41065]

FrSky introduces a complete Series of Archer Plus and Archer mini Receiver ( RS Mini, RS+, R6+, GR6+, R8+, GR8+, SR8+, SR10+, R10+ , SR12+, R12+, R6mini, R6mini-E, SR6mini, SR6mini-E )

hopefully there will be a solution

[pfeerick]

Real life has intervened, so Raphael hasn't had time to work on this (or much of ETX the last few weeks) ... normal service should resume soon 🤭

[kochpet]

The ACCESS protocol is one of the most advanced protocols on the market. The new Archer Plus series receivers are an essential part and should definitely be integrated into EdgeTX, otherwise EdgeTX will become uninteresting for FrSky users in the future.

[gagarinlg]

1. FrSky has no interest in EdgeTX, so support for new products might or might not happen
2. EdgeTX is a hobby for us. Some things are way more important than hobbies. Please be patient.

[DRZ400]

the sr10+ is supposed to be accst compatible, is anyone has tested it with their new lua ?