FrSky ARCHER PLUS R10+ and SR10+ receiver support #3188
Comments
|
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. |
|
Hi Raphael, 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! |
|
@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. |
|
@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. |
|
@rotorman can you please help this gentlemen with the pinout of the internal module connector? It is the same as on the TX16S. |
|
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. |
|
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. |
|
You are looking for a "normal" async serial ( This is the code for the current receiver settings as we know it: edgetx/radio/src/pulses/pxx2.cpp Lines 397 to 419 in 5f17156 |
|
@rotorman on the X10S IXJT motherboard is a 13pin Molex and not a 12pin like at your photo. |
|
@rotorman |
|
@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. |
|
@raphaelcoeffic |
|
@raphaelcoeffic did you find time to check the Saleae logic file? |
|
@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). |
|
@raphaelcoeffic Sorry, I zipped the wrong file, here are all the .sal of the various switching processes. |
|
@kochpet did you actually have "Telemetry disabled" activated? It seems bit 7 is always set in your traces, which seems odd. Also:
|
|
@raphaelcoeffic Yes telemetry was disabled |
|
@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 |
|
@raphaelcoeffic let me check, I make a new trace |
|
@raphaelcoeffic this is the trace when i open the OPTIONS menu |
|
The receiver sends 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. |
|
This is the caprure for the High PWM Speed mode |
|
@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 |
|
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. |
|
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 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. |
|
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 🤭 |
|
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. |
|
|
the sr10+ is supposed to be accst compatible, is anyone has tested it with their new lua ? |
|
@raphaelcoeffic |
I need to get back to it. Probably when I get back from vacations (beg. August). |
|
@raphaelcoeffic |
|
Maybe some posts could be a hint here too: |
The receiver name table is really not the issue.... What did not work here was the output mode. It's harder to reverse engineer than just finding a string table in a binary (have fun with Ghidra ;-)). Top of the table: Bottom of that same table: But you know, neither me nor any other dev from this project does use this gear. So, yes, we could maybe provide some little fan service, you can be sure that as long as nobody actively tests it regularly, it will be very unreliable and incomplete. Other vendors provide us with the full package:
|
|
@AlphaCharlyX it would help much more if you could find a dev using FrSky/ACCESS willing to support their gear ;-) (warning: some reverse engineering involved....) |
|
Did someone asked FrSky for the needed information? I think FrSky 8s interested to sell the Archer plus Receivers to OpenTX and EdgeTX -users as well? |
FrSky has abandonded OpenTX, sees EdgeTX as a threat and tries to force people into their closed eco system. A while ago someone from FrSky said, that OpenTX and EdgeTX are old and have a bad software quality. And for OpenTX this is not far from the truth, some parts are not well maintained. But on EdgeTX we are working on those parts, to have a good base for future developments, so that we are able to use STM32H7 MCUs and maybe MCUs from different manufacturers. FrSky wants everyone to move to Ethos. If you are able to get infos from FrSky, feel free to share them and maybe someone will implement it. I am pretty sure that they are not willing to share any information. As for me personally, except for then BnFs with Spektrum, I have switched almost everything to ExpressLRS and I do not plan to invest any money or time on FrSky gear, with the exception of testing already supported radios. |
|
Problem has been solved in OpenTX |
|
@AlphaCharlyX Do you have one of the newer supported receivers? You should be able to try out #4077 then ;) |
Including the additional options for the configurable ports? I haven't seen anything related to that, but I might be wrong. |
|
Please keep in mind: OTX has only added some support - around being able to OTA flash the Rx IIRC, those changes don't include the ability to configure the Rx (which is what this issue is in regard to). So #3249 is still in a state of "need some help testing" before this issue is solved. |
|
Does anyone know if the GR6+ also supports remappable pins? I'm contemplating getting one, else it will be the R10+... looking at the manual for the GR6+ it seems like it has that capability also? Just doesn't seem to be mentioned in the manual or specs in any way... |
|
As far as I know, all Plus series receivers have remappable pins! |
|
Everything should be available, if something isn't, let me know. The issue for pin map was the wrong model id check |
Sorry to disagree with that :) |
|
I get it from there... |
I must wait for the nightly version? Sorry for asking (newbie) :-) |
We'll fine out... I'm getting the hardware to check :-P |
For OTX changes yes. For ETX, niether #3249 nor #4077 are merged yet so you would need to either using the automated builds avavailable for one or the other depending on what specifically you are wanting to test or build your own frankenbuild via Gitpod |
|
Gentlemen, the test party is going right here: #4077 |
Is there an existing issue for this feature request?
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
The text was updated successfully, but these errors were encountered: