Mike Blandford

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

I've been using a FrSky Taranis or Taranis plus since before 2014 and not had any radio problems. I'm just moving to a FrSky X20. All electronics, and the associated firmware, can suffer from failure, and with the number of transmitters in use, all makes are likely to have a few problems. The more transmitters of any particular make are in use, then there is a greater likelihood of a transmitter of that make having a problem. Mike

I log the telemetry for every flight, and move the log files to my PC when I get home. The logging is started automatically when the motor is armed and the throttle has been at more than 20% for 2 seconds, stopping when I disarm the motor. Mike

I have a model using a FrSky Neuron ESC that reports the ESC temperature using telemetry. When first flown there was no direct ventilation for the ESC and the reported temperature reached 75 C. I added a small scoop on the side with about 0.5 inch by 0.3 inch opening facing forward. There was always an air passage through the entire fuselage to an opening at the rear underside. The ESC now doesn't report a temperature over 35 C. The model flying characteristics haven't changed, although it is quite large, 5 feet wingspan and powered at over 800W at full power. Mike

Version 80 of the UNI firmware is now published. This adds FBUS support, for control and telemetry, to all receivers (on the SPort signal). X6R,X8R,X4R etc. enable telemetry, regardless of how the bind was done, when not activated. G-RX6 and G-RX8 allow the built in vario to be disabled, hold the "bind" button pressed for 4, or more, seconds to toggles the setting. The blue LED will flash 3 times to indicate the action. To enable FBUS you need UNI-Setup6.lua (or later), or XxRsetv5.bas for erskyTx. Included with the LUA file is a LUAC file in case radios do not have enough memory available to compile it. Files are here: [URL="https://forum.alofthobbies.com/index.php?threads/uni-receiver-firmware-release-files-universal-accst-d16.3270/"]https://forum.alofthobbies.com/index.php?threads/uni-receiver-firmware-release-files-universal-accst-d16.3270/[/URL] This update is only required if you need FBUS or to be able to disable the built in vario. Mike

That feature does not, currently exist in UNI. Having had a quick look, it is easy to add. I already have code to detect a press of the button for 4 seconds or more, used by the R-XSR to toggle CPPM on/off. I've just tested the change and it seems to work as required. I just need to make sure it only operates on G-xxx receivers. It will therefore be in the next revision of UNI. This should be available very soon as I've been adding FBUS support, as an option, to all supported receivers. The testing of that has gone well so is about ready to release. Mike

I've been adding FBUS support to UNI. I appear to have this working on all supported receivers. There was a problem with the X8R, and similar, receivers due to the transistor inverter on the SPort input being too slow for the high baudrate (460800) of FBUS resulting in the data not being read reliably by the UART. The problem was the transistor output was late when the output changed from low to high. I solved this by capturing the signal edges using a timer and DMA, then processing the data into normal serial bytes. Knowing the low to high change was late I adjusted this before doing the processing. This appears to work reliably. FBUS is currently being tested, although there are not very many able to test it fully. I've tested using a FLVSS-ADV, which works OK, but I have no way to test the control output. It has been checked by someone who has a device that logs the output, and the same device logs an official output so it seems correct. Mike

Exactly! I had to build my first computer (you couldn't buy them at the time), then design a fast cassette interface! 8" floppy drives in the loft, with an old computer with 5.25" and 3.5" floppy drives, so yes, I can still read them. USB DVD writer available so I can use DVDs even if a new computer doesn't have a DVD drive. Mike

As far as I'm concerned my data is mine! It is not going to be stored anywhere other than on my hardware. I have two, USB hard drives I use for backup, and back up all my data (all kept in a specific directory), every day using alternate backup drives. I also have two hard drives, removed from previous computers, installed in USB enclosures that are also used for backup. Mike

The DJT is no longer legal in the UK and Europe! In any case, it only supports The FrSky 'D8' protocol and the older 'V' protocol. The XJT does also support the 'D8' protocol, but is really intended for the 'D16' protocol that the X8R uses. I just checked a XJT in my TX16S and it works fine (so the hardware is OK, I don't know about edgeTx as I use erskyTx). Mike

I just ran a few tests using a FrSky D8R-PLUS (FrSky D8 mode): X9D+ with DJT module gives RSSI over 100 at 5 feet. 9XR-PRO with XJT module in D8 mode gives RSSI over 100 at 5 feet. TX16S with internal MPM in FrSky D8 mode gives RSSI around 85 at 5 feet. (Yes it was fine tuned). A couple of external MPMs in FrSky D8 mode give RSSI around 100 at 5 feet. I've always suspected the MPM gives lower output power, than FrSky modules, when using the CC2500 RF chip. I have several MPMs and they all show lower RSSI, some more than others, with, in my case, the internal module of the TX16S the lowest. Every 3db lower reduces the range by 30%, 15db down would reduce the range to one sixth. Mike

The LUA scripts are here: https://github.com/offer-shmuely/frsky-accst-uni-rx-scripts/tree/main/edgeTx/SCRIPTS/TOOLS You need "UNI-Activate.lua" to activate the Rx. UNI-Statistics.lua provides useful performance information. UNI-Setup.lua allows you to configure various options available with UNI. Mike

UNI firmware is here: https://forum.alofthobbies.com/index.php?threads/uni-receiver-firmware-release-files-universal-accst-d16.3270/ The second post of that thread has a Guide (in pdf format) explaining how to flash and use it. The version of openTx (2.2.3 in your case) does not matter, the firmware for the X8R needs to match the firmware in the internal XJT module. If you have downloaded "X8R X6R FW20180322.zip", then it is likely that is the firmware you need for the X8R. If you go for the UNI firmware, this automatically detects the firmware on the internal XJT at bind time. If you ever update the firmware on the XJT module, then UNI will just need binding. Mike

Sorry the XM+ uses a different processor that doesn't have enough flash/RAM for UNI, and also needs a specific compiler. Please look at this thread: https://forum.alofthobbies.com/index.php?threads/uni-receiver-firmware-release-files-universal-accst-d16.3270/, go to the second post and read "Universal ACCST Guide.pdf". Let me know if you then need more information. Mike

What firmware are you running on the Tx (openTx, erskyTx, edgeTx)? Mike

UNI firmware for the R-XSR is now available. Mike