Mike Blandford

I've just posted an update to v58 for the RX8R-PRO (UNI_rx8rpro_58sm.zip). This should fix the problem (which was specific to the RX8R-PRO, it is OK on other receivers). It also includes the SPort polling rate reduction if too much data is being submitted on the SPort. Mike

You may, of course, download and flash V57. Your Rx is "activated", so it will remain activated when any updates are flashed. SBUS in has input hardware that prevents it being used as an output. UNI for the G-RX6 and G-RX8 should be available very shortly. During testing of this, it has been discovered that external SPort sensors, combined with the internal sensors data, can exceed the rate that telemetry can be sent by the Rx. This is particularly true if you use an openXsensor as the firmware in that has a couple of bugs causing it to send data more frequently than it should. UNI therefore will have a method of limiting the polling on the SPort to avoid this when too much data is being received on the SPort. This will be incorporated into UNI for all receivers. Mike

You say "Horus X10S, EU Ver 2.1 bound in D16 Ch 1 to 8 mode", I think this means you are not sending anything for channel 9! If you discover sensors you should find a VFR value (Valid Frame Rate). Go to the UNI Release Files linked above and download XxRsetv2.zip and XxRstatv5e.zip. Extract XxRsetv2.lua and XxRstatv5e.lua and put these on the Tx. When you run the XxRstat script, the Rx, if it has UNI firmware on it, should fill in all the values. Go to page 2/3 and you should see the firmware version number and the mode in which it is bound. If you then run the XxRset script you should be able to see and change, the various settings. Mike

As far as I know, the NFL issue and the USM issue are not related, but the NFL issue cause is not known while the USM issue is fully understood, and is a problem in the Rx. Mike

There have been a small number of NFL failures reported over some years (NFL = No Failsafe Lockout, there is a thread on RCGroups about them). Some of these have lasted a few seconds, some 20-30 seconds and some for a few minutes after which time control was recovered. There is some evidence that power cycling the Tx recovers the link. As these have happened very rarely, there is insufficient information available to locate where any fault is. There is also some evidence that telemetry continued to operate while there was no control. I did manage a test using a XJT module in a Taranis (running erskyTx firmware) where I stopped the Tx sending data to the XJT, but kept the module powered. The module continued to send the last control information it had. Mike

When the incident occurred, you turned the Tx off. After recovering the model you then turned the Tx back on. Was the Rx powered all the time, and you then found the elevator was working correctly or did you power the Rx off and back on? Mike

The second problem is fixed by a small change to the code that was committed on Feb 25, 2022, file oXs_out_frsky.cpp. Starting at line 1745, change: } else { TxSportData[0] = 0x10 ; TxSportData[1] = 0 ; into } else { TxSportData[0] = 0 ; TxSportData[1] = 0 ; Mike

I've just discovered that the openXsensor firmware has some errors in it when sending FrSky SPort data. 1. Altitude and vertical speed are transmitted as fast as possible where there should some rate limit such as only every 100mS or 200mS. 2. Sensor items that are polled but don't have any new data should reply with a packet of all zero bytes, but they actually respond with the first byte not zero, so equivalent to always sending data. The combination of these two problems is an openXsensor can request the Rx to send more data than the radio link can handle, particularly for receivers such as the G-RX6 and G-RX8 that also have internal sensors that send data. This will result in loss of data so some sensors may not be able to return data very often. Mike

Your Rx battery voltage looks very low for a 6v NiMh battery. 5.5V is quite low, and it drops to 5.2V around 31:47. I just checked an old 4-cell 730mAh NiMh battery and I see 5.1V driving Rx, FLVSS and a servo on a servo test mix from the Tx. A well charged 5-cell battery should be showing 6.3V when lightly loaded. Mike

What firmware do you have on the Tx module and the Rx? Do you know if they have "V2" firmware? Mike

As usual you need to consider the complete system, not just the servos. If the Tx/Rx combination doesn't get data to the servo frequently enough then having a digital servo with data being sent every 9mS, or less, may well not gain a quicker response. As a specific answer to the OP, I've used a lot of EMAX servos and they have all performed well. Mike

Just for information, if you have UNI firmware running on a FrSky receiver, you may set individual servo outputs to be 9mS or 18mS. Mike

Also puzzled by the aileron setup, I would use UP aileron to try to reduce tip stalling (effectively providing washout). Mike

A small bug has been picked up where the setting to enable mapping of SBUS output channels is not retained through a receiver power cycle. A fix for this has now been posted here: UNI release files. The files are in uni_57u.zip. These are "Update" files so only work on receivers that are already activated, they do not include the activation feature. The XSR is now fully working with UNI. Uni for the RX4R and RX6R are also now released. There is a single firmware file that runs on both. This also runs on the G-RX6 and G-RX8 and includes support for the built in vario. The vertical speed value currently has incorrect scaling but otherwise is working. The altitude value is also functional, although these receivers have some drift in the reported value (also noticed with FrSky firmware). I'm looking into whether it is possible to reduce this drift. All release files, including scripts, are being posted in the same place. Mike

Pity the electronics diagram shows AND gates when they are actually NAND gates! There should be small circles on the outputs indicating the output is inverted. Mike

I've just checked the only Spektrum receiver I have, an AR6210-X. The signal that drives the THRO output includes a 180 ohm series resistor. I looked because FrSky receivers also include a series resistor, the purpose of which is almost certainly to protect the processor driving the signal from external injected voltages. I would expect other receivers to have similar resistors in the outputs. What this means is if an ESC draws a small current from the signal when it is high, the voltage at the output of the receiver will be lower than expected. As you add more ESCs to the signal, it will get lower still, and may therefore no longer be high enough for an ESC to detect properly. If it is possible on your Tx, can you make a second channel output a copy of the THRO channel, then use the THRO output for 2 ESCs and the copy channel output for the other 2 ESCs. Mike

I first flew electric in the mid 1970s. The model in my avatar dates from 2002. At that time it was powered by a "buggy" motor, geared 4:1 supplied from 10, 2000mAh NiCds. It did full ROG and was (is) fully aerobatic. The model itself was built quite lightly, the 52" span wing weighs only 9 oz, complete with 3 servos (2 aileron and 1 for split flaps). I had the flight timer set for 8 minutes. In 2007 I fitted a brushless motor, and changed to using 12, 3000mAh NiMh, which gave even better performance. It does now use a 4 cell, 3000mAh LiPo, although being somewhat lighter than when using NiMh it is slightly worse in windy conditions. So I agree that the history in the article is not accurate. Mike

I'm still using my FrSky Taranis X9D+ as my main Tx for flying and I've been using this for over 8 years with no problems. I have 10, production FrSky transmitters, and a few prototypes, and I haven't had any failures in normal use in more than 9 years. I also have over 20 receivers and quite a lot of telemetry sensors, several Tx modules and several ESCs. The only failures are two receivers and these were caused by me applying incorrect power connections when doing some involved development work! Mike

I have mine set to 370, handles lead free solder as well as 60/40. It is very likely the switch was soldered in with lead free solder. What I do for components like this is to add enough solder (60/40) so it connects all three prongs at the same time. That way, when the solder is molten, the switch may well fall out by itself (all pins desoldered at the same time!). Sometimes, a bit of pressure from the soldering iron will push it out. After the switch is out, then use the desolder tape to clean the board and holes to allow the new switch to be fitted. Note that with many boards, any ground connection may include a ground plane (a large area of copper connected to the pin). This acts as a heat sink and makes it more difficult to get the connection hot enough, which is why you may need a high temperature. As with any soldering a high temperature for a short time is better than a lower temperature for a long time. Mike

When I was flying with NiMh batteries and brushed motors, 50W/Lb was more than adequate for reasonable flight, and the motor was much less efficient. I'd agree the battery voltage would have been more than 11.1V, I see at least 11.6V at 25A after 1 minute of flight on my flight logs, so 11.8 off a full charge would be my guess. This is about 300W, and the Ammeter will be dropping a small voltage as well. I reckon it should fly OK. It won't be fast, a 600kv (looks to be 660kv from my search for the motor) motor on 3S won't give a large RPM. The motor appears to be rated at a max. of 55A, so running at 25A is very conservative. Personally, for 660kv, I'd be looking at using 4 cells and a smaller prop (11x6ish). Mike

It looks like I may have the solution to why UNI firmware has poor range on the XSR receiver, so UNI is likely to become available for that Rx as well. Mike

Does the white connector fit in the G-RX8? If so, no soldering should be necessary. Each of the wires has a small connector crimped to it. These crimps are retained in the connector housing by a small tab. Using a pin, or similar, gently prise each tab end (part furthest from the wire entry) and you should be able to (gently) pull the wire with crimp out of the housing. Note which way the crimp was fitted into the housing. Now just push the crimps back into the housing in the required order. Look at the side of the G-RX8 and the 4 positions are labelled +, -, AIN and a symbol that looks a bit like a 'S'. Place the wires in so: Red to + Black to - Yellow to the 'S' White to AIN The yellow wire my already be in the correct position (looking at your picture). The other end of the cable with the white connector is also not correct, the red and black wires need to be swapped over. Again, these have crimps on them and a small tab holding them in place. Using a pin again, it is possible to pull these out from the black housing and replace them swapped over, you want the wires in the order of yellow, red black. Then just put the white connector in the G-RX8 and the black connector in the FAS40. Check carefully before powering on that the signals do connect in the correct order: - to - + to + 'S' to 'S' Mike

The G-RX8 should have come with a cable to plug into the small, 4-pin connector of the Rx, mine did. This should have three wires going to a Futaba style connector, which is the SPort, and this then plugs directly into the FAS40. Mike

When binding in ACCST, there is an option to set the Rx to output channels 9-16 instead of 1-8. Perhaps try configuring channel 9 on the Tx to have a mix and see if the channel 1 output of the Rx then controls a servo. One other question, while the servos are not responding, are they being driven to a centre position (so the Rx is outputting pulses)? Mike

Please confirm you did bind the X8R to the Tx so you now have the green LED on solid. 1. If you turn the Tx off, does the Rx then turn the green LED off and start flashing the red LED slowly? 2. On the Tx, from the main screen, press the PAGE button (several times) to get the the "CHANNELS MONITOR" display. When you move the sticks, do the "bars" move? Mike