Mike Blandford

It is quite possible. The 12-character code is from the processor unique ID, but to use it in full would result in a 20-character code, so the 12-character value may be the same on two receivers, particularly if the processors are from the same batch. This is quite possible if they were purchased at the same time. Mike

In addition the the receivers listed there, UNI is also available for the XSR and R-XSR. Mike

UNI does avoid the swamping problems, as the RSSI value becomes very high it turns off the front end amplifier and reduces the telemetry transmit power. Mike

The RTC battery only keeps the clock running, model data is either in EEPROM, flash memory or on the SD card. Mike

I assume you are certain they are RX8R PROs and not RX8R (the "PRO" text is difficult to see!). UNI firmware on the Rx will eliminate the need to make sure you have compatible firmware on the Rx. Mike

The X4R and X6R probably have V1 firmware on them. You could flash them to V2-LBT, or UNI. As a quick check you could try binding them using the MPM and select FRSKYX D16 (for FCC) or FRSKYX EU for EU-LBT) and see if they bind. Mike

The UNI (ACCST) firmware that runs on some receivers is also available for D8 receivers converting them to use D16 mode only, see here: https://www.rcgroups.com/forums/showthread.php?3391195-FrSky-D16-firmware-for-D8-receivers&perpage=20 Mike

I've just flashed the internal module of my (prototype) X9D+ with XJT_ACCST_2.1.0_LBT.frk, and the D8R-IIplus I had bound (in D8 mode) is still operating, so D8 is still supported on V2 ACCST on the XJT. Mike

I just checked a Taranis X9D plus and with the module flashed to V2 FCC, then the D8 protocol is still available on the module (this Tx pre-dates the change to needing EU-LBT firmware). If all your existing receivers are using the D8 protocol, then updating the internal module to V2 should leave all binds to existing D8 receivers still OK, but then let you bind to the R6 mini. Regarding the multi-protocol module (MPM), early firmware only allowed for 32 protocols. A change was then made that allowed 64 protocols, then another change increased this to 256 protocols. It seems your version of openTx came out before the last change, so only supports 64 protocols, even if the module supports more. To be able to use all the protocols in the MPM needs openTx to be upodated. Updating openTx should not affect the internal module and receivers bound to it. It may, however, update the models in the Tx, so these would then need to be fully checked. If you do choose to update openTx, make a backup of both the model memory (EEPROM) and flash memory so you are able to restore these. UNI firmware is NOT available for Archer plus receivers as they already support ACCESS and ACCST(V2). Mike

That's saying that UNI firmware is ACCST only, not ACCESS, so on an ACCESS Tx you need to select ACCST (D16) if the RX6R is flashed with UNI. Mike

T9 are showing the RX6R, in stock, at £30.96. This is a full range, 6-channel receiver that is quite small (21.1×17×7.3mm, 2.9g). While it shows as a ACCST (D16) receiver (UNI firmware also available), ACCESS firmware is also available for it. MIke

Try something like setting a logical switch to a>x Thr -80 AND switch SCv then use this as the switch controlling the 10% mix. The rudder will then only be mixed in if the throttle is advanced far enough that reducing the output by 10% will not stop the engine. Mike

Servos typically rotate +/- 60 degrees for full stick throw. For the rotation from 0 to 10 degrees, the linear movement is about 17% of the radius while for the rotation from 50 to 60 degrees the linear movement is only 10% of the radius. This actually results in (approximate) negative exponential. So if you use some exponential you compensate the servo rotation. The rotation of the control horn on the aerodynamic surface will similarly provide some positive exponential, although the amount of rotation of the surface is generally significantly less than 60 degrees, so you still have some negative exponential in the geometry. I just did a test on erskyTx and I need about 40% expo set so the linear output of the servo is the same for the first 10 degrees of rotation and the last 10 degrees of rotation. Mike

tHE idS USED ARE DEFINED IN THE FILE "oXs_config_advanced.h": // ***** 1.2 - SPORT_SENSOR_ID used (only for Frsky Sport protocol) ***** See list of available values in oXs_config_descripion.h #define DATA_ID_VARIO 0x00 // = sensor 0 used for Alt and Vspeed #define DATA_ID_FLVSS 0xA1 // 1 used for Cell values #define DATA_ID_FAS 0x22 // 2 used for vfas , current and fuel #define DATA_ID_GPS 0x83 // 3 used for GPS data #define DATA_ID_RPM 0xE4 // 4 used for rpm, T1, T2, airspeed #define DATA_ID_ACC 0x67 // 7 used for Acc X, Y, Z #define DATA_ID_TX 0x0D // used to read data sent by Tx in order to adjust some oXs parameters (flow sensor or ppm) You need to change the values there for the second sensor, then flash it. Probably change the values back after. If just using current and voltage, the DATA_ID_FAS is the one to change. Mike

Regarding the 4-in-1, multi-protocol module (MPM) use in the RM TX16S, pretty well all the protocol implementations are "reverse engineered" and have no support from RadioMaster. I have significant confidence in the person who does most of the work on the MPM, but it doesn't alter the fact that most, if not all, of the implementations are NOT based on documentation from manufacturers. At some point, a while ago, I found, and provided a fix, for a bug in the DSM code. It is known that for some protocols (those that use the CC2500 chip) it is necessary to do fine tuning of the transmission frequency. This can only be needed if the hardware (crystal frequency) uses poor quality/accuracy components on this chip. It is not known if the same is true for the other 3 RF chips so these may have similar poor frequency control, but as they don't support frequency tuning it is not easy to test and find out. Mike